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

["Butler, Gerald" <gbutler Jewels COM>]

> -----Original Message-----
> From:	Paul Davis [SMTP:pbd op net]
> Sent:	Thursday, October 03, 2002 11:48 AM
> To:	Butler, Gerald
> Cc:	'Carl Nygard'; 'MHL Schulze t-online de'; gtkmm-list
> Subject:	Re: [Re:[[gtkmm] technical question: GTKMM_LIFECYCLE] 
> 
> >> "petitioning the GTK+ crowd to use gtk_object_unref()
> >> instead of gtk_widget_destroy() in gtk_container_destroy(). then we'd
> 
	<SNIP>

> >lasts the longest. 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?
> 
> yes, that is the purpose of "manage" as currently implemented, but its
> predicated on the way GTK+ containers work.
> 
> the central question:
> 
>    Gtk::Foo *foo = new Foo;
>    Gtk::Container *bar = new Container;
> 
>    bar->add (foo);
>    ...
>    delete bar;
> 
>    // is foo is still a valid C++ object a this point?
> 
> in many common GUI applications, there is no reason for foo to be
> valid any longer - adding foo to bar was intended to allow bar to
> manage its lifecycle, hence:
> 
>        bar->add (manage (foo));
> 
> works to make this explicit. for many people and situations, this is
> exactly what you want to happen.
> 
> however, there are other cases where its not. in those cases, you want
> to the lifetime of foo to be determined by the longest-lived reference
> to it. if thats bar, fine. but perhaps its something else.
> 
> with GTK+'s current model, there is no way to do this. this isn't a
> requirement of GObject, the underlying C object, its a design decision
> implemented by GTK+. other GObject-using APIs can make a different
> design decision that supports the "longest-lived reference" model and
> GObject will support that too. but gtkmm doesn't because GTK+ doesn't.
> 
> i believe that GTK+ made a mistake in this design decision, but its a
> mistake that i have to admit i have never been affected by in any way.
> 
	Aha! Now I think I understand the argument. Please allow me to
summarize.

	1) M.C. Says, GtkMM does things exactly correctly because:

		a. It has default C++ automatic memory management on the stack
		b. It has default C++ dynamic memory management on the heap
		c. It supports the Gtk dynamic "manage" memory model
		d. All is well and good!!!

	2) The GstMM developers say, "No there's a problem":

		a. We want to do something *like* manage, but not exactly
		b. The way we want to do it is different then the way Gtk, and
as a result GtkMM, does it
		c. We need our new way, because our underlying GStreamer
classes, that GstMM wraps, implement it this way - unlike Gtk
		d. We want to use "manage" to do what we want, but we want it
to be semantically different from what GtkMM::manage does
		e. That's OK because, we are wrapping "GStreamer" which is
based off "GObject" whereas GtkMM wraps "Gtk"
		
	3) M.C. says, "Oh No! We can't have *manage* have two completely
different semantic meanings in C++ wrappers for Gtk related stuff. It will be
too confusing to the end users."

	4) The GstMM developers say, "But we're not Gtk related stuff. We're
GStreamer/GObject related stuff. So, your point is moot."

	5) Hence, a huge, gaping, monstrous schism between the two sides as to
what is *CORRECT*.


	Does all this summarize correctly? If so, I'd like to add by 2 cents
to the discussion. I believe, in my humble opinion, that what the GstMM
developers want to do, they should do. However, I agree with M.C. that calling
it "manage" would be extremely misleading and confusing to end-users.

	Saying that Gtk implements it improperly is like saying that the
definition of a line is incorrect. It's axiomatic. *manage* is, by definition,
absolutely correct in its behaviour. It does *exactly* what it was intended to
do. I really don't see how you can argue that something is wrong, if it
performs precisely as intended. The best you can say is, there is another way
to think about the problem.

	I think having something *like* manage under GstMM is the best
solution. Perhaps it should be called "container_reference".

	Thank You for this opportunity to give my opinion.



 The information contained in this e-mail message is privileged and/or
 confidential and is intended only for the use of the individual or entity
 named above.  If the reader of this message is not the intended recipient,
 or the employee or agent responsible to deliver it to the intended 
 recipient, you are hereby notified that any dissemination, distribution or 
 copying of this communication is strictly prohibited.  If you have received 
 this communication in error, please immediately notify us by telephone
 (330-668-5000), and destroy the original message.  Thank you.