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

I basically agree with what Dan says about complexity, so I won't include it
all again here.

> From: Dan Shafer
>
> 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.

Just for comparison, I opened up Visual Basic, created a Button then opened
the editor and typed the button name followed by a dot (period) and up
popped a list of 50 attributes and methods for the button. Of that list of
50, around 32 were directly changeable via the Properties editor, so I'm
assuming the rest are methods. A text field had a list of 67 items with 42
of those changeable in the Properties editor. In VB what you see is what you
get, so that level of complexity is always shown and you can't get anymore
functionality.

I tried to figure out the same numbers for a HyperCard Button and Field but
due to how properties and messages are listed in the references and the fact
that HyperCard Buttons and Fields are also popup menus, lists, radio
buttons, checkboxes, etc. I don't know how to do a direct comparison. Maybe
it was good that HyperTalk didn't have autoComplete? ;-)

In Python, we don't have declarative static typing, so I can't get
autoComplete in a Python-aware editor, unless the editor is going to do some
evals on the source as I type and make some assumptions about the variable
type when have code that can't be evaluated because a calling function isn't
written yet, the function or method I'm writing isn't done, etc. PythonWin
does some guessing and it is a mixed blessing. So, in general, lack of
explicit typing means only the runtime environment can give you an
autoComplete list, any editor we eventually do probably won't be showing any
attributes or methods.

Anyway, the level of exposed complexity is probably relatively easy to
control, but if we want to hide anything it will require extra work. The
runtime environment tools such as the Shell can have a setting to control
how much is shown and any documentation that is created can be built with
one or more users in mind.

Patrick hides the complexity of wxStyledTextCtrl in the shell by only
showing those attributes and methods he explictly defined to be shown.

We can remember the users level of "sophistication" just like other
properties so you don't have to constantly change back and forth.

The framework automatically binds all applicable events to a component, but
again this is something that we could change so that only events with
handlers are bound and so "Hide unused events" in the Message Watcher would
go away. We originally bound all events because it was simpler to code that
way and it more closely matched what HyperCard did.

The one big problem with juggling what you show and don't show is that if I
user defined their own variables or methods that match something already
defined in the underlying classes, but not shown, then they will probably
get confusing results.

ka