Re: [anjuta-devel] Scons Support in Anjuta

[Sébastien Granjoux <seb sfo free fr>]

Hi,

Le 31/08/2010 13:12, Abderrahim Kitouni a écrit :
> 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).

Ok, I see. But I don't think it's a problem here because you cannot copy 
a AnjutaProjectNode. Each AnjutaProjectNode is owned by its parent which 
has a pointer on it. If you copy it the new node hasn't a parent so it's 
a different node. I think reference counting such object is not useful 
because the reference count is always 1 (new object) or 0 (the object is 
free).


> 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 haven't checked the numbers, they could be wrong. But I think a boxed 
type will not fit because as I have explained above an AnjutaProjectNode 
is really a node. Its address is stored in the parent node and its 
sibling, so it you move it to another address it's not the same node 
anymore. I don't see any need to copy a AnjutaProjectNode so I don't see 
the user of such boxed.

I have seen a GLib.GPointer object but I haven't understand its use.


> 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).

Yes, it's wrong. After writing this mail, I have done some search and I 
have seen that python bindings at least allow to subclass GObject. It 
think it's the minimum to bind GObject.

But then, I don't understand why libpeas hide the GObject plugin object 
but it's another discussion.


> What do you mean by less hack that GObject? (I assume less work than to
> convert to GObject)

I means that a GObject is something really complex, which is supporting 
derivation, properties, virtual function, signals, run time type checking.


> > 1. We write a anjuta_project_node_new that is creating a GNode having an
> > AnjutaProjectNodeData as parameters.
> 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).

I'm agree that I should hide the fact that it is a GNode, it doesn't 
matter for backend in other languages. But, I don't understand why it 
should be register as a boxed type. For me it should be just a number.


> > 2. Better, the anjuta_project_node_new has an additional gpointer as
> > argument and create a AnjutaGenericProjectNodeData which is an
> > AnjutaProjectNodeData and a gpointer.
> 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.

Yes, need 1 or 2 not both. The advantage of this solution is that it 
should be easier to get the specific data from the node number, you 
don't need to look in a hashtable.


> > 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 think we would be reinventing some wheel here,
> g_type_class_add_private does the same thing more or less.

Yes, g_type_class_add_private data does the same thing for a GObject, 
but AnjutaProjectNode is not a GObject so I cannot use 
g_type_class_add_private on it.


> 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.

Ok, but read only is less useful. As autotools is the main project 
format is not possible for it.


> Yes, that's the point: most structs in GLib aren't used in bindings
> because they provide basic functionality available in most languages.

Yes, I have looked in python bindings and I have not seen any bindings 
for most GLib objects. But I don't understand what's happen when you 
define a function that is using one of the GLib structure. By example 
how do you implement a function in python which has to return a GRegex 
object ?

Or does it means that all arguments and return values should be limited 
to gint, gchar, gchar *, gfloat ?


> But the backend needs to know how to free this structure (witch is going
> to be opaque, right?).

Not really. I think the type of an AnjutaProjectNode should be seen by 
the backend as a number like a gpointer.

Then, if we are using solution 1 above. I think it's not the best one 
but the one which should work anywhere.

The implementation of the ianjuta_project_node_new in the backend should 
be something like:
- call the C function anjuta_project_node_new, it return a number which 
is a pointer but you don't care except that it is 64 bits on a 64 bits 
computer.
- Then, allocate additional data for your project in a node object. 
Associate this object with a hash table to the number above.
- Return the number above.

The implementation of the ianjuta_project_node_free in the backend is:
- Find the data corresponding to the number of the node and free them.
- call the C function anjuta_project_node_free on this number


I don't see how we can avoid this free function. But the backend doesn't 
need to know that the node number is in fact a pointer as all access are 
done through C functions.


Or, perhaps the issue is that some language don't have a numeric type 
which is able to contains a pointer ? In this case, yes there is really 
an issue.

Regards,

Sébastien