Re: [anjuta-devel] New project interface and introspection

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

Hi Abderrahim,

Le 05/09/2010 15:05, Abderrahim Kitouni a écrit :
> Thanks for looking into this.

I'm glad to have your replies too.


> I don't think this is ok. "the object doesn't belong to the caller"
> means that the caller doesn't need to free it, which is wrong IMHO.

I think it's right, because the AnjutaProjectNode pointer is really used 
as an handle. For the caller, this handle doesn't correspond to a memory 
location and it doesn't own the memory. The caller has to manually 
handles allocation and deallocation of such object. I think it's similar 
to file objects in python where you have to use open and close.

I think (transfer full) can not work on a C structure, because the 
caller doesn't know how to free it.


> By using this workaround, we take the risk of causing memory leaks, so
> I'd prefer something else.

I'm checking what is the cost of using GObject and what is difference 
between (transfer none) and (transfer full). Indeed using GObject is 
probably easier for the caller, so I will try to check more in details.


> Yes, a gpointer parameter gets passed a python object as is, you just
> need to add some get_extra_data function or something.

Ok, I will try this.


> So we're left with a problem only in Vala. I can do some strange casts
> with which I need to be careful not to lose memory, but I'd prefer
> something like:
> void anjuta_project_node_set_extra_data (gpointer data, GDestroyNotify notify);
> (and a corresponding get_extra_data). That would completely solve the
> problem of backend-specific data.

I think you don't need this GDestroyNotify function, because all nodes 
have an associated AnjutaProject object which is really a GObject and 
which has this destroy notification function. It's the 
ianjuta_project_node_free function. You have to call your destroy 
notification function here.


> If the save function doesn't return a value (IMHO, if the save function
> is in the node itself, it shouldn't return a new node) then it could be
> a signal instead of a virtual method.

Yes, but it's a workaround. Do you know if this limitation is only 
temporary ?


> GObject has finalize/dispose, and code for freeing things should go
> there. (and we could even use g_object_new directly if we can get the
> GType).

Sure, if I'm using GObject, I could avoid the new and free functions.


> btw, I've (finally ;-p) understood how properties work. It seems a bit
> complicated and relies on the fact that lists are doubly-linked.

Congratulations, it's indeed a bit complicated.


> Wouldn't it be better to keep 2 lists, one for the default properties
> and one for the overriding ones? That would be simpler, but may be more
> expensive.

It's sure that it costs one additional pointer: 4 bytes in each node on 
a 32 bits machine. On the other hand, it's sure that it's more 
complicated. I have chosen the complicated solution for the moment but 
I'm agree that the gain is quite small so I'm not sure it worths it. If 
I'm using GObject it is definitively useless.


> I'm not sure about this, but I feel that a list should be just a list,
> even if that would require more copying from backends written in dynamic
> languages (as they have their own lists).
> Anyway, need to think more about this.

This is a common issue with external container (I mean having a pointer 
to some custom data instead of deriving from a common node object), like 
GNode and GList. If you pass the real data (AnjutaProjectNodeData 
pointer) you cannot go back to the node object.

For the project nodes, it is really useful to get all children of a 
nodes, so I really need to keep GNode pointer.

For properties, it is perhaps less important and in the worst case we 
can probably look in the whole list to find the corresponding GList item 
from a property data pointer.

Moreover, having the list of properties as a real list will be easier to 
use for bindings. I think it's less important for node, because I don't 
think there is a generic tree object in introspection annotations.

Regards,

Sébastien