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