>*excited voice on* This alone is an *even more emphasis* Amazing
>Discovery, but look what you get in addition FOR FREE *excited voice
>off*:
>
>1. You don't have to remember if a column has to be "unhidden". Maybe
>there are color names that contain commas!
Ruediger,
I thought the exact same thing when I discovered MetaCard's array
mechanism. Most of your problems could be solved by simply creating an
array in a global. Multi-dimensional would be cool, but besides that most
of it is already there.
>2. Some properties may be dynamically resolved. Maybe some property
>"level" which is calculated from the score a player has and certain
>groups he or she is in. You can even turn a static property dynamic
>and change nothing but the class itself. Say you want to add the role
>title to the name that is generally displayed, just change the
>property into a getProp handler and all is done!
Of course this is very easy (and one of the cool things in TADS, because
it makes no distinction between methods (=functions) and properties), but
you could implement this "by hand" if you used accessor functions to get at
your array items. Each object's array could contain one array item "class"
which your accessors switch on to perform any special behavoiur.
But this is a good point. Though it's currently possible to easily create
arrays, there's no equivalent to getProp/setProp there. But maybe we could
find a compromise: If we used the "master object" approach discussed in the
"classes like icons" thread, you could simply create your objects in a
hidden group. You'd have inheritance and you could use your custom
properties. Since they're in RAM, the overhead would be pretty low.
>If you have three
>creatures on a chart, you'll have to sum up thir weights to find the
>load of the chart. Without caring about what kind of creatures are in
>the chart (you have an array of long ids in a property of the chart)
>you can add their weights and the Orc "getProp" handler will be
>called.
This would also be easily achievable using the above mechanism. Just make
sure you list only objects with the same basePart.
>Of cause you can encapsulate most of the behaviour by using
>functions, but you can not send function calls to a different stack,
>you'll have to program two handlers for each and every single
>property, and the calling code looks not as nice and natural as it
>does with properties of custom classes.
Well, SuperCard has "via" to send a function to another stack...
>Of cause you can use custom propoperties of controls to achive some
>of this functionality, but depending on the application there may be
>no "physical" control representing the object, so you can create
>invisible objects or even a stack that contains them
Maybe something that would help here would be to support "homeless"
objects, or we could create something like the clipboard, that is, a number
of storage containers for objects.
new button "Pete" in storage1
set the owner of btn 24 to storage3
This way you could say
set the property of btn 1 of storage3 to value
and at closing your stack you could say
delete all buttons in storage3
to get rid of them (does MC have an "all" identifier? It could use one).
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
