At 10:41 Uhr -0600 09.09.1999, Scott Raney wrote:
>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.
That is not exactly what I said... I would very much prefer to use
this syntax, but there are other things that are more important to me
(like a tree view ;) or pictures and links in fields.
> > What if unsupported syntax gets turned into a handler call?
>
>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).
A better example would be:
spill x over y
And in a later MC release a new stochastic operator "over" would be added.
Hey: How about adding your own operators (just kidding ;)
> > 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...
It would be better, if this was a stack property.
And coming to that (again), would it be too much work to add two
stack properties "compatibleWithVersion" and "savedWithVersion". We
have a stack saved in version 2.4 with both properties set to "2.3".
If the stack is opened with a version 2.5 MetaCard engine, all kinds
of checks are made to see, if any of the feature new to 2.5 could
break this stack. If they could, the compatibleWithVersion property
is set to 2.4 and the new features are disabled, otherwise to 2.5. In
any case the "savedWithVersion" would be set to 2.5, so the checks
won't have to be done multiple times.
To reduce the effort, the checks could be done in xTalk or even by
hand. Only the engine would propably need a major rewrite, so I bet
we won't see this very soon, if at all. But it is a nice idea, isn't
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 |
--------------------------------------------------------------------
