names [Was: Approach of new Object methods in ES5]

Peter van der Zee ecma at
Mon Apr 19 13:27:43 PDT 2010

On Sun, Apr 18, 2010 at 2:45 PM, Sam Tobin-Hochstadt <samth at>wrote:

> On Sun, Apr 18, 2010 at 3:56 AM, Peter van der Zee <ecma at> 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
> samth at

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list