At 21:20 Uhr -0600 06.10.1999, Scott Raney wrote:
> > I dont see xTalk as a beginners-only language!!!
>
>Agreed, if we do it right. If we don't, it's not going to be a big
>improvement over C++ or Java, and may end up being worse because at
>least you get pretty much unlimited flexibility with third-generation
>languages.
But you have to agree that we *can* do it right!
> > 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 "*".
>
>Is there any real benefit to going though the "class"'s structural
>heirarchy here? The only reason I can think of would be to get
>around script length limits.
Script length limit is 2 Gig now, isn't it?!? :-)))
I had thought some people could wonder why the message never passes
through the natural parent of the class object. If everybody agrees,
i'd be glad to not have 2 or more additional steps in the message
path.
>And note that I used "class" instead of "owner", which is already
>the term for the structural relationship (HyperCard's name for this,
>and not one of the better design decisions they made IMHO).
I did not want to use "class" because it is not exactly that in
theory. But I do not really care what it will be called... that is
more a question for when you learn it.
> > 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
>
>Then why even have them be stacks? Why not make up a new object
>type for them? Doing so would complicate the storage problem a
>little (you'd probably have to attach these objects to a stack
>somehow, for example), but completely eliminates the nastier aspects
>of trying to use "physical" objects as classes: the ambiguity over
>whether "physical" properties, like the rect, are inherited or not.
>With a pure virtual object, this problem goes away.
Agreed. (I suppose you are talking about the objects defining the
classes, not the objects themselves) My suggestion was that any
object could define classes, but I agree that it would be better to
make classes a new object type. I was too much thinking of problems
like the script editor not working on non-physical objects, but that
is no problem at all for MetaCard, is it? :-)))
So a class is a class object itself that has some properties of its own:
set the name of class "usr" to "user" -- use this wisely!
set the storageStack of class "user" to "foo"
and the other way around
get the classNames of stack "foo"
Class names could be local to a stack or global if the stack is "in
use". The engine should throw an error if there are class name
conflicts within one local name space or within the global name
space. Different stacks can use the same class names and a stack can
override the global class names.
> > 3. Setting a class name also generates a global function "the
>> <class>Names", e.g. "the playerNames".
>
>All the members of the class accessed sort of as globals? Could be
>powerful, especially for do-it-yourself garbage collection. It's
>unlike other OO systems, though.
Well I had thought that our intention was to be NOT like other OO systems ;-)))
> > 4. Objects can contain other objects (just like cards contain
>> controlls) that are disposed of if the containing object is deleted.
>
>This is not a problem so long as the contained objects are of this
>same "class" type. It'd get hairy real fast if the contained
>objects can be "physical" objects, though.
I can not see any need to do that. I want to put creatures into a
house, but certanly not buttons; they have nowhere to be displayed,
so what would they be good for?
>And if they are [class types as well], you're still not making a
>distinction between class and instance, which is one of the key
>principles of OO language design. Not that anybody's going to shoot
>us if we don't follow the dogma, but we'd better have a very good
>reason for doing it a different way...
My first experience with OO languages was with smallTalk, then C++
and many other "OO enabled languages"; and I must admit that it was
not straight forward to me that in AppleScript *any* object can be
used as a class. We have not discussed that explicitly here, but if
you look at classes more like dynamic templates, then any object
should be useable as a template for other objects. I think this
concept is easy to grasp if you are new to OO, but difficult if you
already are used to think in the other, the classical way, where you
look at classes as abstractions rather than as objects themselves.
Actually this classical view is very much inspired by the concept of
ideas that Plato had and thus this is more like a philosophical view,
while the other is more educational.
As supposedly most people using MetaCard are casual programmers or
beginners, I think for the majority the non-classical concept is
easier to get into, and those that are experienced can learn the
concept fast enough.
Extending the list of feature requests:
6. There had been a proposal that private methods should be
implemented. Maybe another feature can be introduced that can be used
for that: A property callStack that returns a list of the handler
names and a property callStackObjects that returns the objects where
the handlers are stored in. A handler can then throw an error if line
one of the callStackObjects is not the id of itself (hey this was
almost xTalk). These properties could also be very helpful for
debugging.
7. Until now we have only talked about properties of custom objects,
but that may not be enough. We may need commands with parameters that
are executed:
send "board intrudingShip,alphaTeam" to spaceShip 1
Which is not very readable or convenient. Maybe we can figure out
some way to expand xTalk into that direction. I had an idea of
calling messages in the third person with the object coming first
(which admittedly makes parsing more difficult):
spaceShip 1 boards spaceShip 2
And the handler definition would start with "it" instead of "on":
it boards anotherShip
With more english like hadler calls this could become:
spaceShip 1 boards spaceShip 2 with boardingTeam "Alpha"
and
it boards bShip with bTeam
Of cause this can come handy in other cases:
btn 1 moves over to btn 2
Now there ist work for at least ten years to implement all of this I
had better stop ;-)
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 |
--------------------------------------------------------------------
