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

[Ben Maurer]

Hello,

First, let me make it very clear what is being broken.

Code will break iff
      * You are subclassing a gtk class
      * You call a constructor other than the default (ie, parameterless
        constructor)

What does this bug fix:
      * It removes the requirement for boilerplate code
      * It leads us on the path to being able to call base (...) for any
        set of parameters while still being able to use the nice OOP
        stuff like overriding. This, sadly, will not be realized until
        we get the metadata to know how to simulate the action of all
        ctors

> 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.
For anyone who has been using the override pattern, they will not be
broken. The *ONLY* way it could break is if you are using the event
based things.


Maybe it would be helpful for you to read the log when Mike and I talked
about this:

> Mar 30 11:12:53 <BenM>	man, this is a sad, sad problem :-(
> Mar 30 11:13:53 <mkestner>	basically, it requires on of two approaches  1) handcode every ctor that has parameters  2) deny use of parametered ctors to subclasses
> Mar 30 11:14:31 <mkestner>	and 2 isn't so much of a solution as a policy decision
> Mar 30 11:14:46 <BenM>	maybe we need to combine them
> Mar 30 11:14:52 <BenM>	`lets work on hardcoding ctors now'
> Mar 30 11:15:09 <BenM>	`but, if we have not hardcoded a specific ctor, you cant use it from a subclass'
> Mar 30 11:17:39 <mkestner>	during generation, we could do property lookups for ctor parameters to see if we could generate a correct ctor
> Mar 30 11:17:53 <BenM>	yeah
> Mar 30 11:18:01 <BenM>	and on the plus side:
> Mar 30 11:18:02 <BenM>	[benm@Ben gtk-sharp]$ find -name "*-api.xml" | xargs grep "constructor cname" | wc -l
> Mar 30 11:18:02 <BenM>	    322
> Mar 30 11:18:04 <mkestner>	I don't know how much that gains us though in practice
> Mar 30 11:18:20 <BenM>	and i bet alot of those are 0 params
> Mar 30 11:19:19 <BenM>	and mabye we can put this in the .metadata, so we dont have to handcode each one
> Mar 30 11:19:36 <mkestner>	well, that's still a sort of handcoding
> Mar 30 11:20:03 <BenM>	yeah, but at least we wouldnt have to change 322 ctors if we needed to change the template
> Mar 30 11:20:38 <BenM>	where you are risking `we' meaning `you' ;-)
> Mar 30 11:48:25 <mkestner>	looks like most of the ctors have params
> Mar 30 11:49:20 <mkestner>	23 ctors in gdk, 20 have params, etc...
> Mar 30 11:49:32 <BenM>	great
> Mar 30 11:49:58 <mkestner>	pango 4/13
> Mar 30 11:50:17 <mkestner>	atk 1/5
> Mar 30 11:52:28 <mkestner>	gtk 67/128
> Mar 30 11:52:47 <mkestner>	so not a fun job to handfix
> Mar 30 11:53:22 <BenM>	not at all
> Mar 30 11:57:27 <mkestner>	not something I can fix for 1.0 for sure.  maybe we should generate exceptions for people trying to connect to those for now
> Mar 30 11:58:07 <mkestner>	basically establish a "you must chain to the default ctor" policy for 1.0
> Mar 30 11:59:39 <BenM>	hrm
> Mar 30 11:59:41 <mkestner>	"unless you provide a .custom to implement a chainable implementation"
> Mar 30 11:59:53 <BenM>	better than nothing
> Mar 30 12:00:05 <BenM>	but still doesnt meet the `not sucking' criteria ;-(
> Mar 30 12:00:11 <mkestner>	it wouldn't technically be an API change
> Mar 30 12:00:27 <mkestner>	yeah, but it doesn't suck more than what we have now
> Mar 30 12:00:48 <mkestner>	and it least it has no hidden buggishness