>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.
Kevin,
yup. This is basically the same as real classes work, but the actual
insight came to me when looking at TADS (a text-adventure development
system with a severe lack of HyperTalk).
>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?
I think this is already in MC. Doesn't it already have certain template
objects and return something like "latent" for inherited attributes? I
think it's already there for colors and fonts, isn't it?
>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.
This is true. But since groups can already be used as backgrounds, maybe
the code from that part could be re-used to allow overriding properties for
any object? So we'd just say: You create a group, and if you base it on
another group, the engine creates new objects that are modeled completely
after he contents of the group. If you delete the contents of the "master"
group, the objects based on it will also vanish (after a nice error message
when running under the engine, of course. I.e. we'd need a new
"deleteMaster" message that can be intercepted).
>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.
Doesn't this sound very much like backgrounds to you? I'm sure Scott can
re-use pretty much code this way.
>(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.)
I'd opt for that, too, but not if it means we won't get this feature until
3.0.
>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.
Sounds sensible. But what if your class calls a utility handler in its
stack? We'd require users to make these calls using "send" or "func() via"
???
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
