RE: [Re:[[gtkmm] technical question: GTKMM_LIFECYCLE]

[Carl Nygard <cjnygard fast net>]

On Thu, 2002-10-03 at 11:06, Butler, Gerald wrote:
> 
> 
> > -----Original Message-----
> > From:	Carl Nygard [SMTP:cjnygard fast net]
> > Sent:	Thursday, October 03, 2002 10:37 AM
> > To:	Butler, Gerald
> > Cc:	'MHL Schulze t-online de'; gtkmm-list
> > Subject:	Re: [Re:[[gtkmm] technical question: GTKMM_LIFECYCLE]
> > 
> > On Thu, 2002-10-03 at 09:02, Butler, Gerald wrote:
> > > 	Pardon me for interjecting, but, I've been following this thread for a
> > > couple of days, and everytime I think I understand either side of the
> > > argument, the next response seems to turn everything upside-down.
> > > 
> > 
> 	<SNIP>
> > 	
> > > 	For purposes of my sanity, can I reiterate my understanding of the
> > > 	5. Now, here's the Kicker -- I sincerely believe I have completely
> > > missed somebody's point. From reading these threads, I feel that those
> > working
> > > on these issues are highly competent and it is my lack of understanding
> > which
> > > is preventing me from seeing the point. Would someone please explain the
> > > problem the new memory model intends to solve with real-world examples.
> > > Perhaps, in trying to explain it to me, one side or the other might gain
> > > greater understanding of the other's point.
> > > 
> > 
> 	<SNIP>
> 
> > "petitioning the GTK+ crowd to use gtk_object_unref()
> > instead of gtk_widget_destroy() in gtk_container_destroy(). then we'd
> > end up with a much more consistent and easy to think about toolkit."
> > 
> > The difference is in how the underlying libraries treat containers.  Gst
> > uses a pure Glib refcount model, while Gtk shortcuts around it and
> > assumes if it's in the container, destroy it, don't just unref it.  If
> > this were fixed in Gtk, Gtkmm would by extension do the same thing, and
> > magically everyone would be consistent.
> > 
> 	Yes, I understand this point. The thing I don't understand is, "Why
> would I want to have the container 'manage' the lifetime of the object if is
> doesn't absolutely ensure the destruction of it?"
> 
> 	This, I think, is the point M.C. is trying to make also. I'm having a
> hard time grasping why I would not want the object absolutely destroyed if I
> surrendered the lifetime of the object to the container. Or, are you saying
> that you really don't want to surrender the lifetime of the object to the
> container; rather, you want the lifetime of the object to be determined by the
> lifetime of the container and the lifetime of any other references, whichever
> lasts the longest. 

I think that's what Martin was getting at.  The code example seemed to
indicate that he didn't want the containers to destroy the child
automatically, only if there were no more refs.


> If so, isn't this semantically different from the purpose
> of "manage" which is to absolutely surrender the lifetime of the object to the
> lifetime of the container?

It would seem so.

> 
> 	Again, excuse my ignorance if I've completely missed the point,

Nah, these are better summaries than what I've seen before, possibly
because I understand them better ;)
 
Regards,
Carl