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

[Mike Kestner]

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>