Re: [anjuta-devel] Scons Support in Anjuta

[Abderrahim Kitouni <a kitouni gmail com>]

Hi Sebastien,
              في ح، 29-08-2010 عند 22:08 +0200 ، كتب Sébastien Granjoux:
> Hi Abderrahim,
>
> > Although I don't like the free_node function, I'm fine with this
> > interface (now that I know it's only 6 methods :-)).
>
> What don't you like in the free_node function ? I think it's necessary 
> if we want to extend the node to add backend's specific data.
Freeing things isn't something you want to do in a high level language
(and that' why I suggested a GObject, you can just unref it and be done
with it).


> > I'm not sure I understand the whole property stuff, could you elaborate
> > a bit?
>
> Sure, I haven't explained how it's working in my previous mail.
[...]
> I hope it's clear enough.
I'll leave discussing this to another post.


> > > The AnjutaProjectNode and AnjutaProjectProperty are not GObject but
> > Why not? ;-) I think a GObject is more bindings friendly (and by
> > bindings, I mean GObject-introspection) and I beleive the implementation
> > could be cleaner. new_node would still be needed (or alternatively a
> > function that would return a GType for a given node type, whichever
> > feels cleaner).
>
> Because a GObject is bigger (not that much I think let's say 2 or 3 
> times) and much slower to create (probably 10 times). Then, I need to 
> rewrite several GNode function, next, previous, parent, child... and the 
> basic GObject function, get_type, init, finalize...
That's right (although I don't agree with the numbers you give), and
that's why I proposed using a boxed type instead.

> I'm not sure it's will be easier for bindings. By example, I think it's 
> not possible to create a GObject in a plugin if we use libpeas and I 
> suppose this limitation comes from the bindings.
That's totally wrong. A binding that doesn't allow subclassing GObject
isn't a GObject binding. (even when using libpeas, the only known
limitations in bindings right now is vfuncs).

> Anyway, I haven't taken bindings into account for choosing this,  if 
> there are some issues, this can be changed. But I think a GObject is not 
> always better, it depends on its use.



> > > It means that the project backend has to create a C structure
> > > representing the project using AnjutaProjectNode.
> > That's the problem I'm facing right now (or rather, I was facing when I
> > last touched this). You have no way to create an AnjutaProjectNode, it
> > doesn't have a _new function.
>
> I haven't created one because it was easy to create in C but I can write 
> a generic one see below.
>
>
> > The problem is that you cannot really allocate "more than the minimum
> > needed" when using e.g. Python (and even in Vala it does require some
> > "clever hacks")
>
> I don't think it will be a problem in Python or Vala or rather I think 
> it can be solved because I think it's less hack than GObject.
What do you mean by less hack that GObject? (I assume less work than to
convert to GObject)

> > [1]. I thought about working around this by keeping a
> > hashtable in the plugin for extra data, but there is the problem of not
> > being able to create an AnjutaProjectNode.
>
> I can think about 3 solutions for this issue.
>
> 1. We write a anjuta_project_node_new that is creating a GNode having an 
> AnjutaProjectNodeData as parameters. Nothing difficult here and that's 
> fine for the interface. But then you probably need additional 
> information in the backend associated to each node, so you can create a 
> hash table with the node address as a key to keep whatever you want.
Sounds ok. Can be better, but this is already enough. And make sure you
hide the fact that it's a GNode (for Vala) and register it as a boxed
(for scripting languages).

> 2. Better, the anjuta_project_node_new has an additional gpointer as 
> argument and create a AnjutaGenericProjectNodeData which is an 
> AnjutaProjectNodeData and a gpointer. In this case you have to allocate 
> all your specific data in a block or memory and give the pointer to the
> anjuta_project_node_new function. So you don't need the hashtable anymore.
This can be a solution, but how memory management is done? (keeping
everything passed to this in a list and removing it on free_node doesn't
sound like a good idea). We won't need both this and the above one, one
can just pass null if they dont need extra data.

> 3. Another possibility is add a sizeof argument to the generic 
> anjuta_project_node_new and allocate additional memory (more than just 
> the size of a gpointer) and put all your specific data here. I'm not 
> sure it's possible though.
I think we would be reinventing some wheel here,
g_type_class_add_private does the same thing more or less.


> > > the save_node function which is really difficult to do.
> > Why would it be difficult? (Unless you mean writing to a hand-editable
> > file, which is a problem of its own).
>
> For exactly this reason. Makefile.am and configure.ac are hand-editable 
> files. I think scons are hand-editable too, even worst it's a complete 
> programming language.
Yes, that's why I'm thinking about making it read only (I'm doing waf,
but it should be the same for scons), and it seems easier with the new
interface.

> > I don't think GMarkupParseContext has binding everywhere (almost every
> > language has its own "xml subset" parser) and is introspection-friendly
> > (the fact that it needs a struct full of callbacks isn't really nice),
> > but being in GLib, it cannot depend on GObject.
>
> Ok, let's say GRegex then or any other object in GLib which is not a 
> GObject.
Yes, that's the point: most structs in GLib aren't used in bindings
because they provide basic functionality available in most languages.



> > I think a simple solution to this is to make AnjutaProjectNode *really*
> > opaque (rather than a typedef of GNode), add new and free functions, and
> > register it as a boxed.  I don't know if this will affect the existing C
> > backends, but if they really need the "allocate more than the minimum
> > memory" trick, then it would be best to just use a GObject (or maybe an
> > extra user_data field will do).
>
> I think it's not a problem to make it really opaque.
>
> I think it can be registers as boxed but I'm not sure it's even needed. 
> I think it can be considered as a simple pointer as the life of the node 
> is controlled by the backend.
But the backend needs to know how to free this structure (witch is going
to be opaque, right?).

Regards,
Abderrahim