Re: closure floating

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On 22 Jan 2001, Owen Taylor wrote:
> 
> > So, have we achieved a resolution here? (I almost said closure...)
> > 
> > 
> > There seem to be two issues:
> > 
> >  1) Whether the approach of any-ref-sinks is acceptable.
> 
> it is acceptable as long as public usages of closures are limited to people
> using it for inlined callback passing, i.e.
> foreach_connect_whatever (obj, g_closure_new (func, data));
> but at least language binding authors will have to do more closure magic
> (implement their own derived thingies, which is another bad locking issue
> btw), so for them you argument to have closures conform to an already
> established lfoating scheme makes sense:

I think yo are saying that you will change it to add g_closure_sink().
Sounds good.
 
> >  2) Whether functions like gtk_container_foreach() should cause
> >     the closure to sink.
> 
> though that's not my personal favorite (i'd rather side with kenelson here
> in every-rtef-sinks) it's probably the better understandable approach for
> glib users.
> however, for that same reason, it's pretty important that any function actually
> taking a closure as argument, subject to possibly inlined closure creation,
> will do a ref/sink pair at its start (independant of whether the closure is
> invoked only conditionally). that assures that anyone creating and passing
> along a closure (which is what 99% of our users will do, we don#t have _that_
> many LB writing freaks ;) knows that he's on the safe side with inlined
> creation.

The question is, not how many language bindings will be written, but
how many people will be using closures _not_ in language bindings.
I've been arguing that the group of people in C who use closures
directly will be pretty tiny.

Closures, are really there for language bindings.

> > For 1), I feel pretty strongly that if we are going to have a floating
> > flag, it needs to be a normal one with an explicit g_closure_sink().
> > 
> > For 2) I probably could accept that gtk_container_foreach() causes
> > the closure to sink, though that seems distinctly odd to me.
> 
> the more i think of it, the less i understand your distinction in
> connect vs. forall here.

The distinction is, in my opinion, really simple:

 gtk_label_set_text()

Doesn't sink the label.
 
 gtk_container_add()

Sinks the child. But anyways, I'm not going to fight to the issue here,
because I don't think closures are going to be used directly very
much.

Regards,
                                        Owen