On Tue, 5 Oct 1999, Ruediger zu Dohna wrote:
> 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 ...
Damn: so many features, even I forget them sometimes ;-)
> 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.
As long as you don't have alwaysBuffer set to true, there isn't much
overhead associated with opening or closing a stack that's invisible
(unless of course you've got some big openStack/closeStack handlers
triggering someplace).
> > > 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!!!
I don't know, this one looks pretty big...
> > > 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.
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.
> >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 "*".
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. 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).
> 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).
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.
> 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.
> 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. And if they are, 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...
> 5. A new "with" expression that allows indexing with arbitrary properties:
> get the name of the player with color = "Blue"
This sounds like AppleScript. And this really doesn't have anything
to do with classes (it could be done for the current objects).
> 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!
It would be. But it's a slippery slope if AppleScript is any guide
(it's nearly impossible to predict what some of these expressions will
evaluate to). Still, it'd be a good thing to include when get around
to doing more database-oriented design and development.
Regards,
Scott
> 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 |
> --------------------------------------------------------------------
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
