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!"