>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.
Scott,
maybe we could call them "private" to distinguish them from local
VARIABLES (after all, in MC you allow declaring local variables with the
"local" keyword, which would cause terminology clashes). Although syntax
like
private on bar
-- foo
end bar
looks a bit wordy, I think it's a good approach and I wouldn't mind adding
that. Of course, getting people to use "private" in their stacks will
probably require a lot of discipline which especially casual scripters
(MetaCard doesn't have that many of those, but SuperCard has, and Serf will
very likely, too) won't necessarily have. But it's a good approach, and it
resembles C++ in a positive way, and brings us a bit closer to "real" OOP
languages, while keeping xTalk readable and easy to use.
>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
If you want to do that, use C++. As you said, SuperCard has "via", and
IMHO it's a good construct. Why shouldn't we use existing syntax? I'm much
more in favor of "via" than of some cryptic C++ construct.
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
