On Sun, Apr 18, 2010 at 2:45 PM, Sam Tobin-Hochstadt <[email protected]>wrote:
> On Sun, Apr 18, 2010 at 3:56 AM, Peter van der Zee <[email protected]> wrote: > >> > >> would be ignored by older browsers. This seems bad because downrev > >> browsers would try to run the script content, unless you use server-side > >> version detection to ship this only to uprev browsers. > >> > > > > How would this work in non-browsers? Does this list care about that? > Should > > it? (I don't know what the main target is here...). Browsers do seem the > > prime candidate here, especially when it comes to multiple versions and > > upgrading. But how are other (non browser) implementations supposed to do > > this? Isn't an language internal solution the way to go? > > There are lots of well-understood solutions for handling multiple > versions of a language in the non-browser context. For example, C > compilers, which handle a wide variety of language dialects and > standards, often use command line switches. It's also possible to > have separate binaries for each version (this is how it works for > Python), or a bunch of other possibilities that aren't available on > the web. > -- > sam th > [email protected] > After talking it through with Brendan this is what we ended up with. He hasn't seen this proposal yet so feel free to take it out on me :) There's a need for extending the specification. Whilst this by itself is an easy task, there are a few restrictions which make it very difficult. Some include not breaking backwards compatibility, using a uniform naming convention and not using "hackish" looking solutions. Basically, this means we cannot introduce new language constructs or syntax because older implementations will trip over the code with no way to recover. Furthermore, for various reasons it seems "feature detection" is favored over version detection. This leads us to a simple addition for detecting the support of a certain feature. ES5 introduced the concept of directives, using perfectly fine fallback with no side effects. This was, as far as the above goes, perfect. Older implementations couldn't possibly trip over it since a string literal without anything else has no visible side effects. There is just one problem with it; there is currently no fool proof way of detecting the support of any directive. There are hacks, but nothing that would be an acceptable solution for the specification. So to this end a simple proposal follows. Whenever any directive was successfully enabled, a globally accessible property by the same should be incremented, starting at one. I suggest to use the global variable. If anything, this is the perfect reason for using the global scope. Better yet, the space in the current (and so far only) directive will make it unlikely to break any existing scripts. Brendan thinks "the global object is a tarpit" and would rather see a different object to be used for this. Object would be best suited since ES5 uses that as well. I believe there's no semantic base to use Object for the detection of enabled directives. However, there are only a few alternatives available since introducing a new variable just for this cause has two problems in one; there's no full fallback without hacky looking solutions: if (window.EnabledDirectives && window.EnabledDirectives["use strict"]). Leaving out the && will make it crash in implementations that don't support it. Anyways, the target object, if not global, can be up for discussion. The reason a globally accessible property would work is because we're just testing whether the directive is supported in general. The reason the property is incremented is if, for whatever reason, the programmer would want to detect case by case whether the directive was followed, he could just compare the values of the property. In any other case, once set the property always evals to true. Note that the ES5 spec simply does not support a directive to be ignored selectively. If it is supported by the implementation, it should always be supported. Hope I caught all the reasoning and problems, but if the language is to be extended by feature detectable constructs... this method would probably be a good candidate. - peter
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
