Anthony: I don't have a problem bypassing the message
hierarchy; that can be done easily.
Alain: Good. What do you propose?
Anthony: I do have a problem with building commands at
runtime.
Alain: This and the above are two different issues.
SEND does not necessarily involve "building cmds at
runtime" We thus keep SEND, right?
> Want to guess how many existing HC stacks become
> incompatible with OC if we don't support do, send,
and
> run-time variable naming?
Alain: LOTS!
Anthony: Not too many. Most I've seen don't make use
of do.
Alain: There was a heated discussion on the pros and
cons of HyperCard's DO command on the HC-List. Most
contributors to this discussion were insisting that
the DO command is one of HyperCard's hottest features.
I am among them.
Anthony: Most that use send only use it to send a
mouseup to a button; quick fix will work there.
Alain: I also use SEND a lot. One cannot mix several
scripting languages inside the same script, so I put a
lot of my AppleScript and MacPerl scripts inside
hidden buttons that are remotely-controlled by the
stack script. I also use SEND to extend HC's
stacksInUse to more than 16 stacks. And I am sure I
could think of many other good reasons for DO and SEND
if it becomes necessary.
Anthony: As for runtime variable naming, hashes can be
used instead. A fairly quick fix.
Alain: A fairly quick fix for runtime variable naming
that doesn't affect the Interpreter. Sounds great.
Let's do the same (or a similar trick) to keep DO and
SEND in NuTalk/OpenTalk.
__________________________________________________
Do You Yahoo!?
Thousands of Stores. Millions of Products. All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
