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


              في ح، 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

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

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)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]