Re: request for g_nullify_pointer and a question about weak refs

[Tim Janik <timj gtk org>]

On 1 Aug 2001, Sven Neumann wrote:

> Hi,
> 
> can we please introduce something like gtk_widget_destroyed() to
> GLib or GObject? Despite from being horribly bad named, 
> gtk_widget_destroyed() is a very useful function for closures and
> destroy_notfiers, but it should definitely live in GLib. I'd
> suggest g_nullify_pointer() and I'd vote for marking 
> gtk_widget_destroyed() as deprecated once we have a better named
> function.

i think we discussed this earlier, at least partially.

owen basically argued in favour of keeping
void gtk_widget_destroyed(gpointer ignored_arg, gpointer *nullify_location);
since:
1) it's usefull to connect to a bunch of signals, without even needing
   to use _swapped variants.
2) people know it already, and it probably has been deployed in a bunch of
   third-party code.

i think that's valid enough for keeping it non-deprecated, however, i'd still
like to see:
  void g_nullify_pointer (gpointer *nullify_location);
since 1) by signature, this function is what i'd look for intuitively if i
were new to gtk/gsignal, and connect it as _swapped, 2) the name actually
_says_ what it does, i consider this a HUGE plus ;)

> One question about g_object_weak_ref(): How is this supposed to 
> work? Imagine you want to create a container that holds weak 
> references to its children.

before we get further into this, it sounds like you'd want to reconsider
your "container" concept. for containers and containees (or items or children
or however you call what you put into it) you usually have clear ownership
specifications. such as:
container_put_item (container, item); -> item is in container
container_remove_item (container, item); -> item is not in container,
                                            maybe orphaned or auto-destroyed
costraints:
item->container != NULL => IS_ALIVE (item)

and thus, in a sane world, you'd never have a function
  kill_item(item); -> auto-removes from container if item->container != NULL
either explicit, or implicit by the container catching item notifications.

yeah, i already hear you screaming that gtk_widget_destroy() is exactly that,
and yes, that's true for Gtk+-pre-reference-counting (if people remember that)
and mostly true for subsequent versions up to Gtk+1.2.
however, it's a very bad misconception to make, and for Gtk+2.0,
gtk_widget_destroy() is nothing but a misnomer, it should be
gtk_widget_break_references() and be documented as 1) auto-removing widget
from container, 2) releasing references to other objects that widget may have.
but there's this "compatibility" thing i keep noticing people talk about and
was informed that that's the reason for staying with the name
gtk_widget_destroy() ;)

> Such a container will most probably
> have some sort of hash table or list where it stores pointers to
> the objects it holds. Now, how is the container supposed to
> remove an object from this list when it gets the destroy
> notification from the weak reference?

conceptually, this sounds more like, e.g. what a cache list would do,
or some similar recall-alive-objects mechanism. and basically, yes,
weak-refs don't currently allow for that, as outlined in the initial mail
of "Subject: Weak references for GObject" (Date: 06 Jun 2001 11:56:35 -0400,
gtk-devel-list) where owen said:

 > If resurrection for cache purposes is considered necessary (I don't
 > consider it so), then I'd like to separate it out into a clearly
 > defined separate facility - something like:
 > 
 >  g_object_add_last_ref_notifier();
 >
 > That can be emblazoned with all the appropriate warnings.

we've had some discussion later on whether to add something like
g_object_add_last_ref_notifier() to our API or not, which hasn't finally
been resolved.
at this point, i'm not sure we'll have that in 2.0 though.

> At the moment, GWeakNotify
> is defined as 
> 
>   void (*GWeakNotify) (gpointer data);
> 
> The only way to pass the necessary information about the container 
> and the object being removed is to create a special struct for this
> purpose that holds both pointers. Why isn't GWeakNotify declared 
> as
> 
>   void (*GWeakNotify) (gpointer object, gpointer data);
> 
> or probably
>  
>   void (*GWeakNotify) (gpointer former_object_do_not_dereference, 
>                        gpointer data);

doesn't the first argument name you picked already answer your
question <hint, hint>? ;)

basically this API is one of those "we don't just allow you to shot
yourself, we even make it _easy_ for you" which we generally try to avoid.

> so one can use the data pointer for the container?
> 
> Is there something that I missed here or is the current 
> implementation of weak references pretty much useless?

it's not generally useless, however it doesn't fit your exact need,
you'd rather use it e.g. for nullifying pointers (_if_ we had
g_nullify_pointer() ;).

> 
> Salut, Sven
> 

---
ciaoTJ