On Thu, 3 Jun 1999, M. Uli Kusterer wrote:
> we've been yakking about some "include" feature on the OpenTalk list
> recently. We'd need it so one can keep a stack's functions around as a nice
> library.
>
> What do you all think about a "libraryStacks" (or "libraryObjects"?)
> property for all objects which specifies a list of stacks that are to be
> automatically inserted into the message-passing hierarchy of any handler in
> the object's script when it's executed?
The concept is good, but the terminology would have to change.
"Library" is already used in several ways in MetaCard for OMO
compatibilities (there is a "libraries" function that's the same as
stacksInUse, a "library" command that's like "start using", a
"libraryStack" message sent when a stack is added as a library, and a
"releaseStack" sent when a stack is removed as a library).
> This would remove the need for "start using" or "insert" and the
> respective "stop using" or "remove" calls in every handler of a script.
> When a handler is about to be executed, the object's libraryStacks are
> start-used, then the handler is executed and they are stop-used again so
> that they aren't accidentally called by another object's handlers.
>
> Penny for your thoughts? (figuratively spoken, of course).
This is very similar to the "parent script" concept discussed earlier,
although your example provides for multiple "parents" and uses
terminology and behavior more similar to what's already available
(perhaps too similar in the case of terminology). But it does
introduce one wrinkle: unlike the "parent script" concept, messages
would have to be sent to your "libraries" at either before the current
object's script or after it had passed all the way through the message
passing heirarchy, whereas parent scripts (I presume) would get the
message immediately after the target. I think the latter would
probably be more useful.
A related issue, and one that hasn't been discussed here yet, is the
issue of "namespaces". xTalk has a very minor version of this problem
compared with Perl/Python/Tcl because scripts are architecturally
separated by virtue of the way they're stored with objects, but it
still is an issue. For example, if two libraries both have a
"doSomething" handler and both are added to the message path, you
wouldn't be able to pick (or even easily determine) which handler
would get called. While a good naming scheme (e.g., prepending the
library name to the function name) would solve the problem, a more
robust solution would require two new features:
1) A way to make "local" handlers that couldn't be called from outside
the current script. Like "static" functions in C, a libraries little
housekeeping utilties would be tagged this way to prevent them from
being called by other handlers by accident.
2) Some way to call a specific handler of a specific object. For
regular handlers, "send" is a reasonable way to do this, albeit slower
(because the arguments must be evaluated) and more wordy. But other
than SuperCard, which has a "via" construct, none of the xTalks can
call a function in another object's script. One way to do this would
be to give names to these "libraries" so that you could do something
like:
put somelibrary:somefunction() into field 1
The names could just be the name of objects, I suppose, but this
doesn't look so hot:
put stack "mylibrary":somefunction() into field 1
Regards,
Scott
> Cheers,
> -- M. Uli Kusterer
>
> ------------------------------------------------------------
> http://www.weblayout.com/witness
> 'The Witnesses of TeachText are everywhere...'
>
> --- HELP SAVE HYPERCARD: ---
> Details at: http://www.hyperactivesw.com/SaveHC.html
> Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
>
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
