RE: [Pythoncard-users] bye bye _delegate, hello direct subclasses

> From: Robin Dunn
> >
> > wxPython uses British English spellings for most if not all of
> its classes
> > and methods (colour instead of color). PythonCard has been
> using American
> > English.
>
> You may want to expose both variants as people already using wxPython will
> be used to the 6 letter spelling.

wxWindows/wxPython provides two spellings in the case of some methods:
Center, CenterOnParent, CenterOnScreen, Centre, CentreOnParent,
CentreOnScreen. How difficult would it be to add name variations for Color
in wxPython if the wxWindows team didn't want to add them? Maybe all us
yanks should just learn to use British English? ;-)

> >
> > We need to be careful to avoid name conflicts with internal wxPython
> > attributes and methods such as this, thisone, etc.
>
> You probably mean thisown, right?

Yes.

> > Most of the PythonCard component methods simply call their
> counterparts in
> > wxPython and we can probably safely get rid of these duplicated methods.
> For
> > example:
> >
> >     def setInsertionPointEnd(self):
> >         self.SetInsertionPointEnd()
>
> An easier way to take care of 1-1 mappings like this is to do
> this at class
> scope:
>
>     setInsertionPointEnd = wxTextCtrl.SetInsertionPointEnd

Good point. When Rowland and I wrote the original code I had only been
programming Python for about four months and Rowland even less and the
solution above didn't occur to me. This is why we need more Python pros in
the development group. So I wonder its possible to do something similar for
methods from the Widget class:

    def _setPosition(self, aPosition):
        self.Move(aPosition)

    def _getPosition(self):
        return self.GetPositionTuple()

where the Widget class doesn't know about wxTextCtrl or wxWindow? We could
do it by overriding _setPosition and _getPosition in Button, TextField...
but that reduces the usefulness of the common code in Widget.

I would like to have the first letter of a method lowercased, but since one
of the main points of this transition is to reduce the amount of work
necessary to create a component on top of wxPython, we probably need to
follow the wxPython naming conventions.

> > As we transition, should we keep the old methods around for a release or
> two
> > or just make a clean break?
>
> If you transition away from the PythonCard *Prototype* to the PythonCard
> *Framework* (or whatever) at the same time then I would make a
> clean break.
> It will probably be simpler in the long run that way.

I can see doing one more release, say 0.6.4 that keeps the old wrapper
methods and then doing a release 0.7 that drops the old methods. Maybe
that's when we should bump up the requirements to Python 2.2 and drop the
Prototype from the package name as well?

I've checked the changes I've made so far into cvs.

ka