Re: RFC: Reference counts on Gtk2::Tooltips

[Andrew Pimlott <gtk-perl-list andrew pimlott net>]

On Mon, May 05, 2003 at 11:40:31AM -0400, muppet wrote:
> this happens because although the tooltips object stores a pointer to itself
> in the client widget's user data, it does not allow that pointer to keep a
> reference.  thus, it is up to the application programmer to store a reference
> to the tooltips object which will outlive the objects which have the tooltips
> attached to them.

Is there any chance of fixing gtk?

> in other words, it behaves as designed.
>
> however, that behavior is rather surprising.  also, from what i can tell it is
> unexpected, since most C code i've seen actually leaks the tooltips objects so
> they stay alive by accident.

So if you preserve the C behavior in Perl, how could the Perl
programmer avoid leaking tooltips?  Basically, you're saying that
every Perl programmer that doesn't want a memory leak has to invent
his own way of managing tooltips.  That seems like a pointless waste
of effort.

> it is trivial to have the perl wrapper for set_tip keep a reference on the
> tooltips object so that it will stay alive; my question is, since it's
> behaving as designed, is this subversion the right thing to do?  or should we
> simply document the behavior in a "pitfalls" or "gotchas" document?

Does the C API have the hooks you would need to dereference the
tooltips when the widget is destroyed?  If so, why not fix it?
People expecting the C behavior would lose nothing, and people
expecting sane semantics would not be surprised.

In general, documenting pitfalls is stupid.  Even in the unlikely
case that a programmer reads it, every pitfall is something else he
has to keep in mind.  If the problem is recognized, fix it.

Andrew