2010/4/20 Brendan Eich <bren...@mozilla.com>: > On Apr 19, 2010, at 5:15 PM, Erik Corry wrote: > >> 2010/4/19 Brendan Eich <bren...@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 > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
