On Tue, 7 Sep 1999, M. Uli Kusterer wrote:
> I don't see any reason not to add this feature to the official xTalk spec.
> As R�diger already said, advanced programmers might prefer not using this
> (since you can then tell apart built-in functionality from user handlers
> and messages), but that's their personal freedom, and no reason to leave
> out this feature. There's only one trouble spot I see:
>
> What if unsupported syntax gets turned into a handler call? E.g. a program
> called TroubleCard has support for English-like syntax as being discussed
> since 1.0, and with 1.2 it introduces the if/then conditionals and boolean
> operators. Now, someone opens a stack in 1.0 that was made to use 1.2's
> features:
>
> on openStack
> if cd btn 5 contains "Steve" then play boing
> end openStack
>
> This would wrongly result in a message
>
> if <cd btn 5's contents>,"contains","Steve","then","play","boing"
>
> In this case this wouldn't be problematic, as the user is unlikely to have
> an "if" message, and thus we'll get a "no such handler" message, but if
> there was such a handler, we'd get surprising results in older versions.
Your example is a problem, but one we already live with. Any command
could be added in a new release: this isn't specific to evaluating
parameters. For parameters, problems like this only arise when adding
operators, which we don't do very often. About the only thing I can
think of that would be likely is if someone tried to use a currently
unused symbol in an expression like this:
split somevar with |
This would be allowed under the new rules, but if we ever decided to
use | as an operator, this statement would break. Of course, it would
be OK if | was in quotes (which it should be). The problem would be a
little worse in HyperCard I think because it allows function names to
be used without "the" or "()" (MetaCard doesn't), but this is really a
problem for the person writing the parser to solve ;-)
> It's something we should consider, and surely document. This is also a
> reason why I think we need one or more of the following:
>
> -> a property to turn off this feature
Sounds messy. Global or local? It would be even better to have it be
tied to the object somehow, but I'm not convinced that this is even
necessary. The only comparable property now is explicitVariables, and
that's been no end of trouble...
> -> a message that is sent whenever a message is sent
> -> a message that is sent whenever a message is not caught
>
> The two messages would allow implementing one's own "Message Watcher"
> window, and would also help in manually debugging such errors, while the
> topmost could help people avoid this error if they don't want to use this
> feature at all.
MetaCard already has these two built in (it's how the debugger works,
although this isn't documented). But there's a pretty huge
performance hit (anywhere from a factor of 10 to 20) so neither of
these would be useful in a stack intended for distribution. And I
don't really see how they would help with the problem of parameter
evaluation.
Regards,
Scott
PS: I and future generations of people looking through the archives
would appreciate it greatly if everyone reading the digest version
would take care to change the subject to match the actual topic rather
than just replying to the digest.
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
