RE: [Pythoncard-users] Script Encapsulation

[Kevin A. <al...@se...>]

> From: Peter Cleaveland
>
> One thing I loved about HyperCard was the nice clean script encapsulation
> it provided.    The samples seem to have all the code in one
> module - while

The one module usage right now is partly due to the limited requirements
document which we're slowly getting past, but the apps right now are still
mostly one background, one window, one module. As Andy brought up in an
earlier message, we probably should change the tight coupling between the
.rsrc.py and module, it is an artifact of the original loader. We'll
probably wait to do that until we are doing multiple backgrounds, multiple
possible layouts for a given background, cards, etc. This is a prototype, so
we get to experiment.

> that's often the best design, it's not as physically intuitive.  Each
> HyperCard object had a script property, making an ideal place to store
> handlers applicable to that object, even if the objects name
> changed or it
> was copied to another stack.  That was always more satisfying to me than
> the all-in-one approach that Visual Basic takes to handlers, where one
> change to the object name breaks every link.  I wonder how hard
> it would be
> to implement script encapsulation in PythonCard.

On one hand, I can't tell you how many times I've held down the Control and
Alt keys and then tried to click on a button to edit its script in
PythonCard while the app is running. Of course, not only were they the wrong
keys, but I'm not even using HyperCard. While I loved being able to get
right at the script for a particular widget in HyperCard it had its own
problems, not the least of which is playing the "where is the script?" game.
A 'mouseDown' handler for a button might be in the card, background, stack,
Home, etc. layers and I don't think it was very intuitive once your code got
more complicated.

We have an issue similar to the VB name problem you mention above because
you have to keep your .rsrc.py component names and your handler names
synchronized. At some point, we should be able to provide some tools to help
identify mismatches, but as long as you can edit any files by hand it will
be a problem. This issue gets even worse once you are saving data that is
tied to the widget names/ids, especially if you're using an object storage
system like ZODB. Changing an id can break the whole app and cause you to
lose all your data. A complete environment can protect the user from that by
controlling all the objects, scripts, and data, but still support different
editing styles.

> Perhaps an object script could be stored as a dictionary of
> functions keyed
> by function name?  Then the script could be a property of an object, in
> true HyperCard sense. Of course, that implies a built in script editor to
> manage the scripts - perhaps a subset of IDLE.  Sigh - I can see it all
> gets rather complicated.

That is probably one approach we'll try. It is going to make life more
difficult, but I would like to always support creating apps using just a
text editor such as Emacs and not force the use of the complete environment
to build every app. Of course, we don't have a complete environment yet, so
right now you don't have a choice. ;-)

The framework has to make sense and work correctly regardless of the
environment we eventually create, so in the short term the scripts will
continue to look pretty much like they do today to the user/programmer.

ka