[Gtk-sharp-list] Re: Ben's GType removal patch

[Todd Berman]

nod, after sending the email, the second issue with regard to ctor
chaining was explained to me, and now it all makes sense :)

--Todd

On Tue, 2004-04-06 at 00:01 -0500, Mike Kestner wrote:
> On Mon, 2004-04-05 at 20:44, Todd Berman wrote:
> 
> > 	Ben has just finished explaining to me that you are planning on
> > accepting his patch to remove the need for the GType stuff. While I do
> > completely support this patch, and would love to see it in CVS, he has
> > told me that it will be committed in a form that breaks '300 ctors' (his
> > words). Why is this even being considered?! I understand that cvs is a
> > place for some breakage to occur, but to check in code with a huge known
> > issue like this seems insane.
> 
> I'll pause for a moment while you read this:
> 
> http://bugzilla.ximian.com/show_bug.cgi?id=55694
> 
> Saying that the patch breaks 300 ctors, while dramatic and eye-catching,
> lacks a certain, shall we say, truth.  The scenario that will be broken
> after the patch is currently broken without the patch and documented on
> the above bug report.
> 
> One "feature" that will "break" with the patch was only partially broken
> before the patch: the ability to subclass a widget without registering a
> gtype and chaining to a non-default ctor.  An example of this usage is:
> 
> public class MyWindow : Gtk.Window { public MyWindow () : base
> ("MyWindowTitle") {} }
> 
> That is currently legal, and will theoretically work unless you ever try
> to use a MyWindow method on an instance ref returned from a Gtk method.
> Gtk# will not be able to wrap the ref as a MyWindow, since there is no
> GType for MyWindow.  It would get wrapped as a Gtk.Window.
> 
> So, the current situation is broken.  The right way to do it long term
> is to force GType registration for all subclasses so that proper
> wrapping will always occur.  
> 
> The problem is that with the new silently registered GType scenario,
> chaining to a non-default ctor will not be possible without first
> manually implementing a ctor wrapper. We'll need to call g_object_new on
> the newly registered gtype and pass prop/value pairs to initialize the
> properties which represent the ctor parameters.  The example from the
> above bug is:
> 
> public MyTreeView (NodeStore store) : base (store) {}
> 
> To do this properly, we need (approximately): 
> 
> public TreeView (NodeStore store)
> {
> 	if (GetType() != typeof (TreeView) {
> 		GType gtype = RegisterGType (GetType());
> 		Raw = g_object_new (gtype, "store", new Value (store), IntPtr.Zero);
> 	} else
> 		Raw = gtk_tree_view_new (store.Handle);
> }
> 
> Of course the patch has more logic to ensure we reuse an already
> registered GType for the new Type, but you get the idea.
> 
> It would be nice if we could autogenerate the ctors like this, but
> unfortunately, there isn't necessarily a direct mapping of ctor
> parameter to property name.
> 
> > 	Please, at the very least fix all the common usages before committing
> > this patch, as setting an acceptable precedent for that sort of breakage
> > seems ridiculous. Considering especially that for the last few releases
> > people have been told over and over again to use the sub-classing and
> > overriding pattern instead of event attachment.
> 
> As I said, it is already broken.  Effectively, this patch just
> advertises that it is broken, by throwing an exception if you try to use
> a non-customized ctor from a subclass.  To reiterate, nobody using the
> existing paradigm of GType boilerplate plus chaining to ctor(GType) will
> be impacted.  I still personally recommend this approach to subclassing.
> 
> > 	Apparently as well, there is no plan to fix all this breakage by 1.0?
> > That sounds even crazier.
> 
> Unfortunately, subclassing will not be 100% functional in 1.0.  There
> simply isn't enough time to get it all done.  Another example of known
> "breakage" will be the lack of Virtual methods for GObject class virtual
> methods that don't have an associated signal.
> 
> You will be able to do a lot with subclassing in 1.0, but it won't be
> fully cooked.  In this case, you'll have to chain to base () and set the
> associated properties in your ctor instead of calling a parametered base
> ctor.
> 
> > 	Am I not understanding something fundamental? Ben hasn't made exactly
> > what is breaking and why clear, and why it has to happen and why there
> > is no better way. Any explanation will help. :)
> 
> I'm certainly open to suggestions of better ways to solve the joint
> problems of silent type registration and base ctor chaining.  If anyone
> has any bright ideas, speak up so we can shoot holes in them.  ;-)
> 
> -- 
> Mike Kestner <mkestner@ximian.com>
> 
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list