[Gtk-sharp-list] Ben's GType removal patch
Mon, 05 Apr 2004 22:26:14 -0400
Just to make sure, will existing code that registers a gtype break?
On Mon, 2004-04-05 at 22:22 -0400, Ben Maurer wrote:
> 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
> 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
> > 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 - Gtkfirstname.lastname@example.org