Re: closure floating
- From: Tim Janik <timj gtk org>
- To: Owen Taylor <otaylor redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: closure floating
- Date: Wed, 31 Jan 2001 09:01:04 +0100 (CET)
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:
> 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.
> 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.
>
> Regards,
> Owen
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]