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

Brendan Eich brendan at mozilla.com
Mon Apr 19 17:40:39 PDT 2010


On Apr 19, 2010, at 5:15 PM, Erik Corry wrote:

> 2010/4/19 Brendan Eich <brendan at mozilla.com>:
>> On Apr 19, 2010, at 4:27 PM, Peter van der Zee wrote:
>>
>>> 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.
>>
>> When you want the new syntax, though, you're going to have to use  
>> opt-in
>> versioning (see RFC4329).
>
> Let's not go there.

We have new syntax in Harmony. We are going there.


> The names proposal seems to be basically ephemeron tables without the
> special GC semantics.

That is over-specification and implementation-as-specification, and it  
will not fly in TC39.


> I'm a great fan of coupling proposals.

Have you heard of the multiplication principle?

I like my odds ratios bigger, thank you very much. I've strongly  
advised Mark on this point and he has adapted his proposals.


> Putting a dozen uncoupled
> proposals into Harmony looks like a recipe for a hodge-podge language.

Hodge-podge is what you get by implementation-as-specification.


> Finding powerful abstractions that solve several problems at once (in
> this case weak hashes and private variables) feels much nicer.

A name abstraction that is concrete in terms of GC, object type  
(typeof), and the possibility of non-leaf Name objects is not abstract  
at all -- it is concretely an EphemeronTable.

TC39 wants sugar for names. But "desugaring" taken too far becomes  
compilation, which is not simple syntax rewriting. It's also  
observable via typeof, Name objects having properties, and other  
effects (I'm willing to bet).

Real abstractions serve use-cases, that is, pressing user needs,  
without implementing abstractions in overtly leaky ways. That's what  
we need for Names, and many other proposals. This does not make a  
hodge-podge if we serve the important use-cases. It makes a better  
language.

If we can unify abstractions without leaks, sure. That's not the case  
here.

/be


More information about the es-discuss mailing list