pythoncard-users

[Pythoncard-users] Script Encapsulation

[Peter C. <pe...@pe...>]

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

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.

Peter

Re: [Pythoncard-users] Script Encapsulation

[Andy T. <an...@cr...>]

I'm channeling Kevin here, and will probably find that our responses 
will cross on the way to the list server, but;

Peter Cleaveland wrote:

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


I'd say this is a great idea as well. It makes it incredibly obvious to 
the user exactly which object their code is tied to. However, PythonCard 
is currently a prototype and this kind of functionality will definitely 
have to wait until someone writes a specific IDE - unless you are 
volunteering? ;-)

The current set up is simple and efficient from a programming point of 
view though, you only need two files for each stack, a resource 
description and a standard python module to include the class that 
controls the stack.

So, if we are to provide an IDE to allow the editing of functions in 
place I would suggest that it would need to be clever enough to manage 
to read and write files in the current format (a bit like resourceEditor 
does for rsrc files). This would mean no changes to the file format so 
that us command line bigots can carry on as normal.

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


There was discussion a few weeks (months?) ago on the list of storing 
the code and resource description in an XML format but nothing has come 
of that. There is no reason we can't do it, just that no one has got 
round to attempting an implementation yet. For the reason above, I'm not 
sure this has legs either but I am happy to stand corrected.

My personal vote would be to maintain the python module format for the 
'program' portion of each stack because then we are still dealing with 
'pure' Python and all of the benefits that brings. For instance, it is 
possible currently to import and test a PythonCard class without running 
it in the framework as, to Python, each module just contains a class.

> 
> Peter
> 

Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"Shave my poodle!"

RE: [Pythoncard-users] Script Encapsulation

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

> From: Andy Todd
>
> There was discussion a few weeks (months?) ago on the list of storing
> the code and resource description in an XML format but nothing has come
> of that. There is no reason we can't do it, just that no one has got
> round to attempting an implementation yet. For the reason above, I'm not
> sure this has legs either but I am happy to stand corrected.

I have to interject my standard XML mantra here which is that "XML should be
created and read by programs, but never seen or edited by humans". As long
as it is likely that we will have to hand edit any resources or source code
I will resist putting them into XML. You'll thank me later :) Among other
things, you can't process invalid XML and so you need an XML editor that can
identify the specific problem line(s), while our current dictionary/list
files can be checked by any standard Python-aware editor or IDE to make sure
they are valid. They are also much easier on the eyes than XML. I guess
nobody remembers that HTML was never intended to be seen or edited by humans
either, but gee look at the mess we got ourselves into.

> My personal vote would be to maintain the python module format for the
> 'program' portion of each stack because then we are still dealing with
> 'pure' Python and all of the benefits that brings. For instance, it is
> possible currently to import and test a PythonCard class without running
> it in the framework as, to Python, each module just contains a class.

Excellent points!

This is also a good time to point out that all the code doesn't have to go
into a single module file. The only code that has to be in the background
class are the handlers for the widget events and even those can just be the
def and then a line that calls a method in a different function or class in
a completely different module file. However, if you need to reference the
background self... it might be more convenient to stick the code in the
background.

Some of the samples use multiple modules and some of the samples use classes
other than the main background. Most of the time when I put "everything" in
the subclass of Background, I was coding rapidly and got a bit lazy. I have
spent very little time refactoring the various samples.

ka

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