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

Peter van der Zee ecma at qfox.nl
Sun Apr 18 00:56:59 PDT 2010


On Sun, Apr 18, 2010 at 7:19 AM, Brendan Eich <brendan at mozilla.com> wrote:

> 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.


Non-string property keys don't need to be hidden. The language could be
extended in such a way where identity properties could be part of it. They
could be enumerable. Some edge cases would have to be resolved of course.

The hidden properties could just as well be strings. You could have a public
enumerable property and one that's private and hidden at the same time.

I can see these as distinct, That's why I'm wondering whether everyone is
trying to solve one with the other or actually pursuing either one (or both)
of them.


>
>
>  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.
>
>
This could be fixed by some kind detection scheme for these directives. When
it would be possible to detect the state of some directive using it as a
versioning scheme becomes feature detectable. Enabled directives could be
made public as the property of some object. Alternatively there could be a
try/catch surrounding some block of code that would fail on an
implementation without the directive and succeed on an implementation with
the directive. There could be a generic method for enabled directives this
way. This would be a workaround though and I'd prefer something
straightforward for detection.

But why was versioning going to be a problem at first and not any more? I
still agree that in the long run, a versioning opt in scheme will add too
much complexity. Both for the programmer (having to enable them one by one)
and the vendor (ditto + support them).


>
>
>  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.
>
>
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?


> 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
>

That was my proposal indeed. This also makes it impossible for introducing
any and all kind of feature that would not be parsable by previous versions
(like introducing new characters or the short function notation). It
actually puts a great burden on the evolution of the language as a whole,
doesn't it? Not sure whether that's a bad thing per se.

- peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100418/edae16e7/attachment.html>


More information about the es-discuss mailing list