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.edwa...@gmail.com> wrote:
On 16 April 2010 13:13, Dmitry A. Soshnikov <dmitry.soshni...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
