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

[Abderrahim Kitouni <a kitouni gmail com>]

Hi,

              في ح، 05-09-2010 عند 16:16 +0200 ، كتب Sébastien Granjoux:
> > 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'm not sure, but I think file objects do get closed by the GC if it
isn't done explicitly.

> I think (transfer full) can not work on a C structure, because the 
> caller doesn't know how to free it.
Yes, that's right. The structure can be marked as foreign but then
static bindings have to be written (somewhat defeating the purpose of
gi).


> > 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.
Yes, it's not strictly needed, I was just thinking about getting rid of
free_node.


> > 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 ?
Theoretically, it is temporary. But in practive, it can be some time
before it's fixed in all bindings. (And personally, I think we don't
need to worry about a limitation if it's only in one binding. We can say
e.g. a project backend cannot be implemented in js for now).

And even though gnome-shell is successfully using signals as workarounds
(see ShellGenericContainer), I actually think signals are good in this
case : a Group node for example could connect to the signal on itself as
well as on child nodes, and get notified if they need to be saved.
(This still needs more thought, but you get the idea)

Regards,
Abderrahim