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

Erik Corry erik.corry at gmail.com
Mon Apr 19 17:50:12 PDT 2010


2010/4/20 Brendan Eich <brendan at mozilla.com>:
> 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?

http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=multiplication+principle
?

>
> I like my odds ratios bigger, thank you very much.

You are welcome.

> 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