New private names proposal

[Brendan Eich]

On Dec 16, 2010, at 5:01 PM, Mark S. Miller wrote:

> At this point, I'll just mention that this response seems overly emotional,

On the contrary.


> filled with name calling,

No.

Calling a specification "obscure and tortured" is not name-calling in any personal sense. However, if you think I've called you a name, I can only back off and apologize.

I invite others to join in with comments on the two proposals, so this doesn't degenerate into something personal -- I do not believe that I've done anything to make it so, and I assume you don't want what you decry here, either.


> and seemingly disconnected from the case I'm actually making.

You're explicitly trying to eliminate one of two proposals, inherited soft fields and private names, which address two different use-cases in different ways, by extending your favored proposal to cover the one, which you don't like anyway. You've been clear enough about this (thanks for pointing out that disclaimer at the top of http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields).

I am calling this backward reasoning, which assumes a conclusion not in evidence: that soft fields are a good specification (or implementation) of private names.

Furthermore, I am clearly arguing for proceeding forward from use-cases and usable designs addressing them, toward specifications and (of course; we do prototype harmony proposals) implementation.

*If* it turns out that two solutions for different use-cases have specification and implementation in common, then we can unify. This must be done _a posteriori_ or we will overcomplicate and over-specify.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101216/d8601395/attachment.html>