Re: closure floating

[Tim Janik <timj gtk org>]

On Wed, 17 Jan 2001, Karl Nelson wrote:

> 
> > > The simplest solution is don't have a floating state for closures.
> > > (Or rather any ref sinks them, thus there is no sink operation.)
> > > Once you create them the first time you use them they are destroyed
> > > unless you reference them yourself.  (This is equivalent to everything
> > > sinks.)
> > 
> > this is equivalent to ref_count==0 at startup, or floating+every-ref-sinks
> > as you say it. and it's exactly the behaviour we currently have in glib,
> > however owens (havocs) argument is that its yet another referencing
> > mechanism introduced, different from widgets which are floating initially,
> > or plain structures that are just ref/unref.
> 
> Agreed, and closures really are plain structures here.  Since 
> there will be 2 management systems (widgets and other) it is
> best to keep the "widget" set as small as possible so that
> you don't have to go read through the docs to figure out which
> it obeys.  If it doesn't derive from GtkObject is should follow
> glib.

note that even with plain glib, there's still one case where we use explicit
floating, but it's usually not a user-visible case:

g_object_class_install_property (o_class, PROP_ID,
                                 g_param_spec_int (...));

the reasoning here is simply convenience to save users from temporary
variables and explicit unrefs of paramspecs after installation.

> Although I did think of other problems with the foobar example.
> 
> void foobar(int p, GClosure* c)
>   {
>     if (p) 
>         g_signal_connect(sig,c); 
>   }
> 
> This seems unlikely, but then is it?
> It is a distinct possibility if you consider the case of
> assertions.

we shouldn't woory about assertions, for assertions, it is clear
that something went foobar already, so further stable/predictable
behaviour can't be expected. with the huge amount of assertions we
have throughout glib/gtk code, you can find numerous examples
where one could try to make a pathologic case "less pathologic"
by doing extra cleanups, but as far as i'm concerned, that's like
substracting integers from infinity ;)

the above:

void
foobar(int p, GClosure* c)
{
  if (p)
    g_signal_connect(sig,c);
}

is indeed a case to worry about though, in effect, such functions
should always be coded like:

void
foobar (int p, GClosure* c)
{
  g_closure_ref (c);
  if (p)
    g_signal_connect (sig,c);
  g_closure_unref (c);
}

to avoid ambiguities. the closure docs should probably include
an appropriate comment, so people taking closure arguments know
to reference count them even if unused.

> 
> --Karl
> 

---
ciaoTJ