At 0:37 Uhr +0200 03.10.1999, M. Uli Kusterer wrote:
> >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),
like in EIFFEL
>but you could implement this "by hand" if you used accessor
>functions to get at your array items.
like in Java
>Each object's array could contain one array item "class" which your
>accessors switch on to perform any special behavoiur.
I don't understand what you mean with "contain". But I do know that
there are different solutions that actually work, but they lack the
elegance that custom classes would have and those nice features of
fully fledged OO like polymorphism are only possible with the class
concept, even though it may have to be adapted to become adequately
xTalkish.
>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.
This is quite exactly what I want.
> >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.
The whole point of polymorphism is to have different baseParts and
not to have to care about that. You can code operations (sum up the
weights) on collections (the chart) without any thought of what kind
of objects it will ever work on, they only need a weight property and
only when you add an object to the collection you'll have to check it
does.
>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.
Use closed stacks without a fileName for the same effect. (BTW: How
about a new syntax "create closed stack ..." to save the performance
hit of opening and closing a stack?) But there still would not be any
inheritance.
I wonder why there is obviously so little interest in custom classes.
The hype of OO being the one and only happy-pill-solution to the
software crisis is pretty much over and we can discuss the real
advantages the concepts have and how we can better make use of them
in xTalk. In my eyes the idea of HyperCard was to take many of the OO
concepts and cook them into a solution that normal people can use.
Modern OO integrated development environments took a lot of that
back, but standard OO languages are still difficult to learn. Why not
move an easy to use language into a direction that makes it more
powerful and even easier to use for professional applications?
If custom classes are not broadly needed, beginners will not see much
of it and not be disturbed. If everybody thinks custom classes are
really cool, everybody will use them and beginners will quickly learn
to use them, too.
Regards
R�diger
--------------------------------------------------------------------
| Ruediger zu Dohna GINIT GmbH 0721-96681-63 [EMAIL PROTECTED] |
| PGP-Fingerprint: F1 BF 9D 95 57 26 48 42 FE F8 E8 02 41 1A EE 3E |
--------------------------------------------------------------------
