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

[Todd Berman]

Just to make sure, will existing code that registers a gtype break?

--Todd

On Mon, 2004-04-05 at 22:22 -0400, Ben Maurer wrote:
> 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
> 
> _______________________________________________
> Gtk-sharp-list maillist  -  Gtk-sharp-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list