At 21:11 Uhr -0600 04.10.1999, Scott Raney wrote:
>On Mon, 4 Oct 1999, Ruediger zu Dohna wrote:
>
>(big snip)
>
> > How about a new syntax "create closed stack ..." to save the
> > performance hit of opening and closing a stack?
>
>A workaround for this in MetaCard is:
>set the visible of the templateStack to false
>create stack "my invisible stack"
>close stack "my invisible stack"
Even better is:
create invisible stack ...
But still closing the stack takes about .02 additional second on my
Mac... not much now, but that may add up to be too slow, especially
when you think that opening it invisibly will propably even cost more
time than closing it.
> > Why not move an easy to use language into a direction that makes it
> > more powerful and even easier to use for professional applications?
>
>I think mostly because it's too hard to do ;-) If this thread is any
>guide, it's may be too hard to even *design*, let alone build...
You already have defeated mightier dragons than this one!!!
> > 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.
>
>We have enough trouble getting beginners using more than a small
>fraction of what's already in any of the xTalk dialects
I dont see xTalk as a beginners-only language!!! We and propably
others do very advanced things with MetaCard (as we did with
HyperCard and OMO) and never regreted our choice. Look at what people
do with RealBasic or even VisualBasic... and those have a terrible
design! Beginners can take advantage of the simple basic structure of
xTalk, but there is nothing wrong if they can transfer the OO
knowledge they have gathered from programming controlls over to
abstract objects and classes.
>My primary interest in the theoretical aspects of this discussion is
>to keep our options open for what we'll be wanting years from now.
>But what we need in the short term are just some ways to extend the
>current structure-based message and attribute inheritance systems to
>include some other ways of doing it. If this can be done with some
>class-based architecture (or some architecture that could be easily
>extended in that direction), great. But the class-based part of it
>is really of secondary concern.
I think the design actually can be quite simple and maybe done in
steps that are not only useful for custom classes, and may have been
discussed before:
1. The owner property to any object that will recieve messages after
the object with the property does. We still have to discuss if the
message should then continue to the "natural parent" of the object or
in the parent of the owner object. I think it is better to have the
message jump back than to wonder why a message never gets to the
script of the stack that contains it, but maybe both:
before-scripts -> object -> owner * -> owner-card
-> owner-card-backgrounds -> owner-stack -> object-card
-> object-card-backgrounds -> object-stack -> stacks-in-use
-> after-scripts
If the owner has a custom owner itself, it is inserted at the "*".
2. New properties "className" and maybe "classAbbrevations" that
allow the script of the object that it is attatched to to be used as
a class name:
set the className of stack "player_class" to "player"
create player "Scott"
set the color of player "Scott" to "Blue"
Note: Classes can work internally like simplified stacks that can not
be opened and have almost only custom properties (name, number, id,
className, classObject, and properties are the only exceptions that I
can think of at the moment). They should have separate name spaces
(i.e. there can be a class and a stack of the same name; name
mangling may come in handy here).
3. Setting a class name also generates a global function "the
<class>Names", e.g. "the playerNames".
4. Objects can contain other objects (just like cards contain
controlls) that are disposed of if the containing object is deleted.
5. A new "with" expression that allows indexing with arbitrary properties:
get the name of the player with color = "Blue"
Throws an error if there is not exactly one.
if there is a player with color is not "Blue" then ...
Existance.
get the color of any player with score >= 500
Returns a random player. Throws an error if there is none.
get the ids of the players with ...
Returns a cr separated list.
Ok, this has nothing to do with custom classes... but it would be cool!
Dont just lurk, participate.... or in other more famous words:
dont dream it... be it!
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 |
--------------------------------------------------------------------
