On Apr 17, 2010, at 6:07 PM, Peter van der Zee wrote:
To be solved:
- Allow non-string-property keys
- Allow "hidden" properties, non-enumerable, not generically
accessible (like stringed keys are now). To be honest, I'm still not
100% clear on this one.
I don't see how these two differ.
Ways of doing that:
- By identity
-- Property is inaccessible once the identity is gc'ed
-- Could cause additional constraints, make an implementation more
complex and heavier in general (circular checks)
- By some kind of private syntax, see the straw for that
The private syntax is so you can use o.p instead of o[x] where x is a
Name object; private p would bind the name p lexically to a Name
object and use it instead of the string "p" when evaluating o.p.
- Simply add new object / instance methods to the language in a sane
sounding way, taking the backwards compat problems for granted. This
is by far the easiest and yet the most opposed way.
This is what ES5 did.
- Add new methods with obscure names in an effort to minimize
backwards compat problems. This is what __proto__ would fall under
(in my opinion). I think that's also part of the start of this
thread and the comparison to "that other language"...
This is not favored by TC39, because the __ convention is no guarantee
against collisions, and it is rejected by some sanitizers.
As far as versioning goes, this seems like an appealing option at
first but can lead to a complex system of rules and versions to be
kept supporting. Basically Brendan's objections. Any versioning
scheme will come down to this, whether it be feature specific (like
an include) or version specific (minor/major version or whatever).
Real web experience suggests feature-testing, or really object
detection, is less combinatorial explosive. Once a browser supports
the new object, the script can use it. No need to enumerate browser or
rendering engine names in a conditional or X-UA-Compatible header.
So. What problem are we trying to solve here and what options do we
have (and are viable) to extend the specification?
For Harmony we have new syntax, so the problem is clear: we need some
kind of opt-in versioning mechanism for authors to use, where old
browsers do not process the new version. This could involve RFC 4329
style
<script src="harmony.js" type="application/ecmascript;version=6"></
script>
but then the question becomes: how does the content author ship an ES3
or lower script to older browsers? See the older versioning page I
wrote, which Collin Jackson worked on too, at
http://wiki.ecmascript.org/doku.php?id=proposals:versioning
An in-language pragma, e.g.
<script>
"use vesrion 6";
// Harmony code here...
</script>
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.
Harmony having new syntax does not mean we are opening up the design
space to make some new, incompatible version of the language. You seem
to allow for that as a possible future course, but TC39 members are
uniformly against this path AFAICT. See http://wiki.ecmascript.org/doku.php?id=harmony:harmony
.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
