Hi,
"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"
I can see where this might get sticky. Why would you want to make btn
"defaultButton" the owner or parent of the new button. Couldn't you just pass on
to the new button the same properties as the defaultbutton?
I can see the advantages of having an extra layer of scripting, but this can be
easily done, simply by "grouping" a single object. The group is the parent layer,
and the object is the child.
>
> 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 the really tricky part. Since the basePart is not in the stack of the
btn, but in the template stack, you will have a real problem if your template
stack is ever separated from the stack you are working on. The only way I can see
around this is if the template stack is actually the mainStack and the stack in
which the child resides is a substack. Think of the standalones that wouldn't
work. Oh, the agony! ; )
Of course, if you made the template an importable resource, it might work. But
things could still get sticky. Consider this scene. You create a child object
from a template, realize that it is not doing exactly what you want, so you go to
the parent object in the template and make a change -- only to realize that you
have changed every other child object that came from that parent!
I like the idea of classes (well, more or less. I am still not experienced enough
to do everything as smoothly as a lot of others seem to). If classes and
inheritance were to be an issue, then I would rather like to see classes
implemented similar to groups or backgrounds, but with the provision that they
would not have to all be visible or used at once. You could edit the class object
by going to it in the same way that you edit a background. The objects in the
class could be seen residing there -- probably a list, with other properties
viewable (card, stack, physical position, etc.). The message hierarchy should go
something like this:
object -> object's class -> object's group -> card -> other backgrounds on card
-> stack -> mainstack.
Did I get the rest of the inheritance issues correct? If we implement class
structures, the class properties and scripts should probably come after the
object's scripts, but before anything else.
>
> 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.
>
> 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
Just my 2 cents worth. You get what you pay for! ; )
Raymond
