Re: closure floating



Tim Janik <timj gtk org> writes:

> On 16 Jan 2001, Owen Taylor wrote:
> 
> > Tim Janik <timj gtk org> writes:
> 
> > I'm of the opinion that setting a closure in a persistant manner -
> > g_signal_connect_closure(), g_timeout_set_closure(), whatever can sink
> > the closure. This is much like gtk_container_add(). But simply
> > _using_ a closure for, say, gtk_container_foreach_closure() -
> > as an argument to a function call should not not sink the closure.
> > 
> > The operation of 'sink' basically represents transfer of ownershop -
> > but an operation like g_signal_closure_foreach() should not
> > retain a refcount to the closure and thus cannot become
> > the owner of the closure.
> 
> unfortunately i'm not sure users will find it intuitive that
> signal_connect() takes over the ownership as timeout_set_clousre,
> but _foreach not doing so.

I'm pretty positive that most users will not find g_cclosure_new()
intuitive at all...

My contention is:

 - the floating flag is only useful when using closures from C
   directly, not from a language binding.
 - user's will only use them from C when they offer enhanced
   convenience, not because they like the look of g_cclosure_new()
 - the only time they'll offer enhanced convenience is in 
   a few cases like setting up a timeout while an object is
   alive. 

> from a simple usage level, they probably want to be able to use
> g_cclosure_new() inlined in all of those function calls, don't
> you think? (and if they still do, while _foreach doesn't sink,
> we'll silently leak closures all over the place)

I don't have much expectation of people at all using C closures
for container_foreach(); if they do, they are doing something
advanced, and I think the best thing we can do is try to make
the behavior predictable and like what we do for widgets, then
try to offer extra convenience by sinking arguments to ordinary
functions.

That strikes me as being the about the same as if gtk_label_set_text()
sunk the widget...

Regards,
                                        Owen





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