names [Was: Approach of new Object methods in ES5]
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
>>>> recover. Furthermore, for various reasons it seems "feature detection"
>>>> 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.
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
> 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.
More information about the es-discuss