On Aug 13, 2007, at 1:11 PM, Paul McNett wrote:
> I just don't see how this particular case (overriding __init__ at the
> user subclass level) will require different user code for different UI
> toolkits...
I'm thinking that things that are implemented one way in wxPython,
such as dTextBox/dEditBox, will be completely different with another
toolkit. There are so many things that go on between the __init__s of
the classes and mixins that have to happen in a certain order that I
do not feel comfortable guaranteeing that a certain value will always
be defined at a particular point in the process. Telling someone that
they are free to override __init__() if they like implies that sort
of promise.
Also, can you imagine this code:
class MySubText(dabo.ui.dTextBox):
def __init__(self, *args, **kwargs):
super(MySubText, self).__init__(*args, **kwargs)
print "This is in the __init__() method"
def afterInit(self):
print "This is the afterInit() method."
How do you explain that the afterInit() code will be firing *before*
the __init__() code does? Do we really want that sort of headache?
Our design is extremely smart and effective. All Dabo users should
be strongly encouraged to work with the framework, not against it.
Just because someone like Uwe insists on paddling upstream
unnecessarily doesn't mean we should ever encourage anyone else to do
the same.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
