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

I'm probably a minority voice in the wilderness here, but that's 
never slowed me down. :-)

I'm more of a Python newbie than probably anyone on this list, and 
I'm also a strong advocate for the non-programmer user (a la 
HyperTalk scripter) that I am drawn to love and nurture and advocate 
for.

For me, it doesn't matter so much whether it is _possible_ to do the 
more complex stuff Kevin outlined in his first message on this topic. 
I do feel like the incredibly long list of properties and methods 
associated with a component in wxWindows is unbelievably daunting for 
most people (even, I would dare to suggest, most professional 
coders). But what's far more important for me is where we choose to 
"drop the tablecloth."

The meaning of that phrase may be self-evident but indulge me while I 
explain just to be sure.

In any programming language or OS, there is a collection of readily 
accessible "stuff" that the primary intended market -- or the least 
savvy intended user, depending on perspective -- is expected to be 
able to see, grasp, and deal with. Then there is a tablecloth. Then 
there is the "other stuff" that only system-level programmers (in the 
case of an OS) or the Language Priesthood (in the case of the 
programming tool) is expected to grok.

For me, in the world of HyperThings -- of which I hope PythonCard 
will be a shining example -- this tablecloth needs to dropped very 
high in that food chain. When we describe PythonCard by saying, as we 
do, that simple programs should be easy and complex programs should 
be possible, we beg the question: easy for whom and possible to whom? 
For me, "whom" is the HyperTalk scripting level user.

I think I know that user as well as anyone, since on many levels I am 
one and since I've spent most of my computing career trying to 
understand and advocate for and support this group.

Allowing for the myopia that creeps in as a result of that focus, I 
want to suggest that as we struggle with this incredibly important 
defining moment in the development of PythonCard, we err consistently 
on the side of hiding complexity under the tablecloth.

What do I mean by this? Let me give a specific example.

In his original message on this subject, Fearless Leader said:

"Most of these methods can simply be ignored, just as most programs only need
the mouseClick and select events and can ignore mouseDown, mouseMove,
mouseContextClick, etc. For programming from the shell we can add a toggle
to automatically hide the base wxPython methods to simplify the autoComplete
list that the user sees most of the time."

I would like to see us take this basically sound approach one step 
farther. Object introspection should be layered so that a 
scripting-level user never even _sees_ the dozens of additional 
methods available for a given component. Those events and attributes 
defined in the present release of PythonCard (subject to further 
investigation and to learning from experience) should be the _only_ 
methods and properties the scripting-level user _can_ get at. For 
this user, the world is simple.

This approach implies that we create another level of PythonCard 
user, the Programming Level User (or perhaps something scarier like 
"Python God" or even "Programming Priest" :-) ) should be able to get 
at all of this directly inherited behavior.

I realize this makes PythonCard terribly schizoid. In fact, this 
design may not even be really feasible given the current level of 
resources available to make it happen. I clearly understand Kevin 
when he says that getting rid of the _delegate mechanism and moving 
to direct subclassing will make his job and that of other people 
helping to develop PythonCard more manageable. If, at the end of the 
day, that means we have to have an environment that exposes all of 
this additional complexity, then I think we need to openly abandon 
any notion of creating this product as the tool for Inventive Users 
for which I remain a staunch advocate.

Perhaps, in point of fact, what we need to do is to create PythonCard 
as a GUI app builder for wxWindows and then create what I now think 
of as PythonCard on _top_ of that platform.

I have little interest in helping to develop a programming aid for 
wxWindows and I would likely never make use of such a beast. But I am 
_passionate_ about a need for a souped-up HyperCard done in Python 
with Python as a scripting language and a strong subset of easily 
used and scripted components with which to assemble new apps and 
create new componentry.
-- 
Dan Shafer, Personal Creativity Trainer and Consultant
Trained Hartman Value Profile Analyst
http://www.danshafer.com/valueprofile.html