Approach of new Object methods in ES5

Brendan Eich brendan at mozilla.com
Fri Apr 16 08:43:35 PDT 2010


On Apr 16, 2010, at 7:17 AM, Peter van der Zee wrote:

> On Fri, Apr 16, 2010 at 2:28 PM, Dean Edwards  
> <dean.edwards at gmail.com> wrote:
> On 16 April 2010 13:13, Dmitry A. Soshnikov <dmitry.soshnikov at gmail.com 
> > wrote:
>
> > I think that approach used in ECMA-262-5 for new object methods  
> contradicts ES nature.
>
> +1
>
> The new API seems quite random. I hope that JavaScript is not  
> turning into PHP.
>
>
> Indeed. The inconsistency and "hacks" is what drives me away from PHP.

Let's leave PHP out if it, this is es-discuss and so far I've seen  
zero evidence of relevant PHP experience.


> I would prefer going by version and having the programmer specify  
> the version somehow. Perhaps like a directive.

No, this makes the Web brittle, besides requiring the onerous multiple- 
versioned implementations (or an implementation with exponentially  
explosive if statements guarding changes and hiding additions).  
Authors would tend to version-lock their content, increasing the odds  
of non-interoperation and failure to work at all on some browsers.

Web authors do not want to write multiple versions of their program.  
Rather, they want to support browsers back to a certain vintage,and  
use object detection to take fast paths and make use of better APIs  
where possible, with graceful degradation.

(A minority position involves server-side user-agent sniffing to ship  
different content depending on UA capabilities, with compilation (e.g.  
GWT) helping automate the "lowering" to run on older browsers.)

Even more fundamentally, a version is just another parameter to get  
wrong, especially on top of the APIs being object-detected or simply  
used without detection. We've seen this in the past with  
JavaScript1.1, JavaScript1.2, etc. At some point IE stopped respecting  
the non-standard version suffix on the HTML4-deprecated "language"  
attribute, forcing all browsers to do likewise.

RFC 4329 does specify a version parameter on application/javascript  
and application/ecmascript, which MIME types it also specifies with  
reference to ECMA-262. However, the values allowed for this version  
parameter are unspecified by RFC 4329, and IIRC IE still ignores this  
parameter (contrary to the explicit language of the RFC -- but no  
doubt IE's behavior predates this RFC being written).

The TC39 committee has pursued two approaches to versioning:

1. Extending the core language's object model (APIs) where name  
collision is less likely, especially in Object (not Object.prototype).  
The larger w3c DOM, Web API, and now WebIDL worlds also try to extend  
API objects without opt-in versioning.

2. Extending the language's syntax with:

(a) No versioning required in the absence of new reserved identifiers,  
since new syntax cannot break existing content.

(b)  Opt-in versioning if new reserved identifiers (even though only  
contextually reserved per ES5, i.e., allowed as property names) are  
already in use as parameter or variable names in web content.

We have talked about elaborating (1) to have a "frame-level" (iframe,  
window) version selection mechanism, so as to avoid name collisions. I  
believe IE8 and above do something like this, based on some kind of  
doctype or META tag targeting a browser by name (should target browser  
rendering engine including JS engine, but never mind!).

Many of us browser vendors on the committee do not intend to ship  
multiple JS engines, or festoon our code with if statements, so  
whether a future standard will version the object model remains to be  
seen.

ES4 since Waldemar's 1998-era JS2 work was concerned with the problem  
of versioning APIs implied by (1) greatly, and not just adding  
properties: deleting and redefining too. ES4 proposed namespaces (like  
Common Lisp packages, IIRC) as the solution. But namespaces are out  
for Harmony.

My hope is that we can avoid versioning the object model and instead  
simply extend certain objects that we effectively "reserve to the  
implementation" (as ANSI and then ISO C does with certain global  
names, e.g. __foo and _BAR). Indeed Ajax library developers now  
generally avoid extending standard prototypes, and it's plausible this  
best-practice could be extended to the built-in constructor objects too.

Object detection is tried and true on the Web. It is not declarative,  
which makes it less efficient and arguably more error-prone -- but it  
fosters graceful degradation and reduces over-large version scope and  
versionitis.

For (2) we had a sketch of an idea championed briefly by Hixie and I  
believe Maciej for syntax error recovery that would allow new syntax,  
generally of the "keyword (expression) { statements }" form, to be  
added to the language.

This still has problems with new keywords, and with future-hostility  
against regexp and other lexical grammar changes. If the idea is to  
allow new constructs among the "statements", it would require full  
lexing and parsing of the entire construct to match the closing }, and  
this would freeze regexp and other lexical syntax, besides being not  
as efficient as the hoped-for "discard tokens till balacing } is  
found" idea that I recall from the initial proposal.

ES5 strict reserves 'let' and 'yield', but this won't get rid of the  
uses of these names as identifiers in existing web content, which  
motivated us to add them in JS1.7 (Firefox 2) only under opt-in (RFC  
4329 style) versioning.

So, more work is needed on (2b), but I do not think being too clever  
(e.g., trying to reserve let but unreserving it once it is seen in an  
unambiguous non-declaration and non-let-expression context) is a good  
idea.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100416/8c78ff98/attachment.html>


More information about the es-discuss mailing list