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

> > >
> > > 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?

Yes, it's doable, and actually fairly easy to do now compared to when I
first started.

> Maybe all us
> yanks should just learn to use British English? ;-)

That's what I've done.  I always have to correct myself when typing colou^Hr
in other contexts.


> > > 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?

As long as Widget is always mixed with something that derives from wxWindow
(pretty safe bet) then yes it should work.

> 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.

I like the leading-lower convention myself, but had to go with the
leading-upper to make the wrappers not be a nightmare.  If you want the
framework to be a mostly complete insulation from wxPython then I think
changing to leading-lower is okay.  Otherwise, if it's going to be a mixture
then consistency is best.  Just be sure that any framework names that
replace the wxPython names have the same parameters and behaviours as the
original to help keep if non-confusing for the user.

--
Robin Dunn
Software Craftsman
ro...@Al...       Java give you jitters?
http://wxPython.org      Relax with wxPython!