RE: [Pythoncard-users] Encapsulation - was Script Encapsulation

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

> From: PeterAndBrian
>
> Yes, I agree we need to maintain the ability to edit and test in IDLE for
> now, since PythonCard IDE does not exist yet.  Yet, it's so NICE to have
> scripts bound to objects.  Perhaps we could have both.

I think we can, I'm just not sure about the actual implementation yet.

> If we added an ID property to all objects, we could adopt a naming
> convention that used the ID in all handlers that "belong to" that
> object.  For instance, we might make a rule that object-specific handlers
> include a pattern like "_[0-9]+_".  Then, the function
> "on_123_mouseDown()"
> could be recognized as belonging to the object who's ID is 123.  And, if
> all _123_ handlers were clustered together in an appropriately (and
> automatically) commented section of the code, they would be
> reasonable for
> conventional IDLE coders to work with.

PythonCard uses 'name' as the id for a component and we're pretty much doing
what you describe above, at least as I understand it. 'name' must be unique
at a given level of the hierarchy, so all the components (widgets) of the
background have unique names. Initially, I thought we would follow the
standard HyperCard method of supporting a name, number, and unique id, where
the unique id is actually a globally unique identifier created by the
framework that is never reused and can't be changed once created. However,
because dictionaries and lists are a fundamental part of Python, it looks
like we can get by with just using names as the unique identifier, at least
for what is exposed to the user programmer and it ends up making PythonCard
more "pythonic" because you have one way of doing an object reference.

> To support object copy and paste between stacks, we could pack up all the
> handlers into a .script property, just while traveling.  Then, on paste,
> they could be integrated into the destination stack.  The IDs
> might need to
> be adjusted at some point. If you copy and paste an object into the same
> stack (or another stack where that ID exists) the pasted object
> will need a
> new ID, and handlers tagged by ID would need to be adjusted.  But that's
> doable.

This is where it gets tricky. Dan Winkler brought this up when I was
chatting with him last week. We were actually talking about copying whole
cards or backgrounds, the layout, graphics, scripts, and data in the
widgets. Since we don't have the environment going yet, I shelved the
problem as any good procrastinator would do. At some point, we have to
evaluate how this is going to work. This is one of the big problem points
when you still support editing outside the environment since an id ('name')
change can cause all sorts of things to break. Simply matching a textual
label as the id through the rest of the code won't work.

There are a number of things I consider warts in HyperCard that we don't
have to recreate. For example, it is often better to create a separate class
to handle a lot of your logic and so the actual handlers associated with a
widget don't need to have all the logic, they just use the separate class.
This increases readability and code reuse. Another thing that we can do at
some point is allow an arbitrary data structure, class, etc. to be part of a
card or background, so that rather than using a hidden Field to store data
as was so common in HyperCard, you can just pickle a Python object and get
all of the benefits without the kludge aspects.

> It all comes back to the lovely simplicity HyperCard provided.
> One stack =
> one file = one application = one window.  OK, the one window part sucked,
> but you see where I'm going.
>
> What do you think about merging all dependant files in a single .py file,
> making PythonCard stacks fully self contained?  Is this feasible or
> desirable?
>
> It would not be too hard to merge the Resourse file into the main
> module.  But what about icons, graphics, sounds - the binary payload
> HyperCard stacks used to carry?  It might never be efficient to
> do this in
> a text based format (base-64 encoding anyone?). That leads us to a binary
> format - a whole stack as one big pickled object?  That doesn't sound so
> great either.

The way to do this will be to have the equivalent of a Java .jar file,
basically a .zip or something with a well-defined manifest describing the
other files in the archive. The .jar equivalent has to be double-clickable
or runnable just like any other .py script, so it will probably be a .pyw
file with some other magic. Yet another project for someone to figure out.
We will have multiple resource descriptions, modules, images, sounds, icons,
cursors, configuration info, user data and all sorts of things that
typically get stuck in the resource fork in a Mac application and in a
sub-directory on Unix and Windows. Many samples already have multiple files.
If somebody solves this problem now, we'll have to revise it as our
resources and modules change with the framework, but that shouldn't be a big
deal.

I would like to get a fair amount of reuse out of the resources and modules,
so that you can borrow whole files from another PythonCard app. I would also
like to be able to break up pieces of the resource file so that we can do
imports for common pieces like the Edit menu, a Find dialog, etc. We won't
have the closed single binary file of a HyperCard stack, so our paradigms
for sharing pieces of an app are going to be different even if many of the
intentions are the same.

ka