On Fri, 10 Sep 1999, Ruediger zu Dohna wrote:
> 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.
Fortunately it would be easier to add than those other two. And it's
not just an academic question. The topic came up here because we're
getting tired of dealing with problems with MetaCard's built-in HTTP
features (proxies in particular are a real pain, and HTTP 1.1 support
is pressing) and would like to have some way to move them back out
into a scripted solution using the new socket support. Even so, it's
looking like we're going to go some other route, so this may not be a
key feature to add after all.
> 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 ;)
Good: it wouldn't be all that difficult to add user-defined operators,
but backward compatibility would be a nightmare if we did.
> > > 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.
Probably so. Unfortunately there isn't anything like that now, so it
would take some work to implement.
> 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.
It is, but would be pretty difficult to implement, especially if you
take into account the regression testing that would be required.
Worse, there'd be a pretty large performance hit associated with it, a
hit that would grow larger with each new release. But 90% of the
problems in this area could be eliminated if people would just not use
common words for variable, property, and handler names.
Regards,
Scott
> 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 |
> --------------------------------------------------------------------
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
