New private names proposal

[Brendan Eich]

On Dec 22, 2010, at 3:49 PM, David-Sarah Hopwood wrote:

>> In arguing about this, I have this bait-and-switch sense that I'm being
>> told A+B, then when I argue in reply against B, I'm told "no, no! only A!".
>> (Cheat sheet: A is soft fields, B is transposed square bracket syntax for
>> them.)
> 
> This criticism is baseless and without merit.
> 
> In order to compare the two semantic proposals,
> <http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names>
> considers what they would look like with the same syntax.

Wrong. That section has

  private key;
  ... base[key] ...

and thus assumes "private key" creates a private-name value bound to key that can be used in brackets. That is *not* how private names as proposed by Allen works, nor how the earlier names proposal worked.

Private names, and names before it, proposes lexical bindings for private names which can be used only after dot in a member expression and before colon in an object initialiser's property initialiser. A private-declared name cannot be used in brackets to get at the property -- not without #. to reflect it into runtime.

Clearly, the <http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names> gets this wrong. Either the names proposal was misunderstood, or the square-bracket-only syntax was a compromise. It simply is not and never was "the same syntax".


> In that case, soft fields are semantically simpler.

I reject all your premises, so it is pointless to argue about conclusions that depend on them.

First, the simpler semantics for a different, inferior syntax does not win over more complex semantics for a simpler and more usable syntax. Users of the language are the audience in most need of simplicity, not implementors or spec writers. The spec is not the ultimate good to optimize in this way.

Second, the soft fields semantic model is not simpler when you count everything it depends on, and where it shifts complexity (implementors and users).

Finally, I disagree that an executable spec, aka self-hosted library code as spec, wins.

But see below -- at this point, it's clear we should not be arguing about soft fields vs. private names as if they are alternatives or in any way substitutable.


>> I'm not saying this was any one person's malicious "trick". But it's clear
>> now what happened; the wiki and list record and diagram how it played out.
>> It leaves a bad taste.
> 
> You have willfully assumed bad faith, despite clear explanations. That
> certainly does leave a bad taste.

No, I explicitly disclaimed bad faith in the cited first line above ("I'm not saying this was any one person's malicious 'trick'.").

Putting up a bunch of wiki pages with the intent of knocking down a different proposal *is* aggressive. I don't think that's "bad faith" and I never said so. Crock cheered it on. In accusing me of assuming bad faith, you are just missing the target completely.

But any such (premature or just wrong) contest between proposals has to compare apples to apples. We can't even agree on the syntax apples, never mind how to compare the semantic model apples.

Even with the best faith (which I presume MarkM has, and he knows this), trying to compare different semantic models, tracking multiple wiki pages, while setting up an elimination-contest context, is "tricky", as in, a lot can go wrong. And (see above, where you repeat the falsehood that Mark's section can_we_subsume_names uses "the same syntax" as private names or names) things did go wrong.

I now think it is a mistake to try to build consensus by separating syntax from semantics, mapping one chopped-down, feature-stripped syntax to both private names and soft fields, and essentially joining in the campaign to make there "be only one" (among two proposals). Here's why:

Private names have nothing to do with soft fields. They are an independent proposal.

Soft fields do not need more than weak maps, which are already harmonious.

If you don't like private names, fine. Maybe they won't make it. Or with feedback from this list and the community, they might evolve to something that gets into a future edition, but soft fields don't bear on the odds at all.

Trying to replace private names with (inevitably  different) syntax mapped to soft fields is not going to please fans of either proposal.

/be