On Thursday, Sept 30 1999, M. Uli Kusterer wrote:
> Hi,
>
> why don't we implement classes like icons are implemented in MC? I mean,
> usually you have a separate card or stack with lots of graphics on it,
> which are then used by buttons as their icons. Couldn't we simply say you
> can use *any* object as a "base class" for another one?
>
> We could allow creating an object based on another one. This object would
> have empty scripts etc., and passing a handler in this script would call
> the handler in the object it's based on. Every object would get an
> additional "basePart" property which is the equivalent to the "owner", and
> maybe a list of "children" that are based on it.
>
> It seems simple and a bit awkward at first, but it's simple, logical and
> powerful at the same time. Some examples:
>
> create button "OK" based on btn "defaultButton" of stack "My Templates"
>
> put the basePart of btn "OK" --> btn "defaultButton" of stack "My Templates"
>
> The message-passing path would be a bit watered-down, though:
>
> cd btn 5 -> basePart of cd btn 5 -> btn 5's card -> btn 5's stack -> btn
> 5's mainStack
This is starting to sound like an xTalk idea I can get my head around!
So basically, an object could have the name of another object to inherit
from, and would inherit any values that weren't set on that object? That
could actually be quite useful, and useable, allowing shared scripts and
sets of attributes, all changeable from a single object except where set on
the instances.
It does raise a few questions though. Wouldn't it be *very* hard to
implement as the engine would need to know which properties had actually
been set on an object, and which were at their default values or had been
emptied?
Also, what about groups? A useful way of implementing a common "control"
would be to be able to place multiple objects together in a group and place
that onto multiple stacks. One example might be to use this to script a
standard list view that gets used throughout stacks. You'd create a generic
view with scripts, and each placement of the group would have individual
properties set on each object at will. So you could alter the rect, color,
text and one or two specific script attributes of some of the objects, but
everything else could be left to pass on up to the "master objects" level
above. But this idea doesn't quite fit in with your original one, because
"placing" a group in the traditional sense would place the whole original
group, and making changes to it anywhere its placed would change *all*
instances.
Which brings about an idea. How about implementing this by creating a way
to "uncouple" a placed group from some other "master" instance of the group.
All objects in that group would be the same as those objects in the master
group, except if you set individual properties inside the instance, when
you'd only end up with the properties of the objects in that instance of the
group being affected.
(And finally, if ever implementing this, wouldn't it be desirable to
implement a new file format that only loads the parts of stacks that are in
use to go with it? One of the uses for this kind of system (as already
mentioned) might be having different ways of presenting the same
information, so storing huge quantities of data in a stack seems like a good
companion to go with it.)
> since here a button in a completely different stack would be inserted into
> the path, and it could get messy determining who should receive messages
> sent by a button's base part when the button was clicked. Should it arrive
> at btn 5's card, or should it arrive at the basePart's card, or should it
> arrive at one first, and if it isn't caught move on to the other one? This
> could be a problem similar to HyperCard's dynamic message path.
To keep things simple, I'd make *everything* work in the context of the
current placement. If you place an object and it has an inherited script,
it runs as if the object is in the placement. If you place a group, the
entire group complete with group script operates in the context of the
current placement.
Regards,
Kevin
> Cheers,
> -- M. Uli Kusterer
>
> ------------------------------------------------------------
> http://www.weblayout.com/witness
> 'The Witnesses of TeachText are everywhere...'
>
> --- HELP SAVE HYPERCARD: ---
> Details at: http://www.hyperactivesw.com/SaveHC.html
> Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
Kevin Miller <[EMAIL PROTECTED]> <http://www.xworlds.com/>
Cross Worlds Computing, MetaCard Distributors, Custom Development.
Tel: +44 (0)131 672 2909. Fax: +44 (0)1639 830 707.
