New private names proposal
david-sarah at jacaranda.org
Wed Dec 22 19:34:24 PST 2010
On 2010-12-23 01:11, Brendan Eich wrote:
> 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,
>> 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.
That section is clear that it is talking about the syntax proposed in
(Adapting it to the private_names syntax is trivial, though.)
The "Name objects as property names" section of that page gives an example
in which 'var name = new Name' creates an object that can be used via
'obj[name]'. The "Binding private names" section says that in the scope of
a 'private x' declaration, "x is also bound as a plain variable to the Name
Therefore, 'private key;' binds the plain variable 'key' to a Name value
which can be used as 'base[key]'. Your interpretation of the names proposal
is wrong and Mark's was correct.
As far as I can see, MarkM has not (at least, not on the wiki) proposed
any new syntax in this discussion that had not already been proposed in
one of Allen's proposals.
> 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
> gets this wrong.
You apparently missed the statement "x is also bound as a plain variable
to the Name value." in the names proposal, which would explain your
confusion on this point.
> 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.
Do you still reject them after being shown that the syntax in MarkM's
proposal is in fact the same syntax?
> 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
This argument clearly fails, because the syntax that you're criticising as
inferior is actually the syntax defined in the names proposal.
There is no obstacle whatsoever to the soft fields semantics being used
with any of the syntaxes that have been proposed so far.
> Second, the soft fields semantic model is not simpler when you count
> everything it depends on, and where it shifts complexity (implementors and
OK, there's an interesting point here, which is the extent to which
reliance on existing language constructs ("existing" in the sense of
not added as part of the feature under consideration), should be counted
toward a new feature's complexity, relative to reliance on new constructs
added together with the feature.
I think that use of new constructs ought to be charged more in complexity
cost than use of existing constructs, all else being equal. This is an
opinion, but I would have thought it's a rather uncontroversial one.
In any case, I don't find WeakMap (or other constructs used by the
SoftField executable specification) particularly complex. YMMV.
The soft fields model does not shift complexity onto users because their
perception of complexity depends mainly on the syntax, which is the same.
The differences in semantics are unlikely to be noticed in most situations.
The actual implementation complexity is no greater for soft fields.
The soft fields specification has a less direct correspondance to the
implementation, and we disagree on the significance of that.
> 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
We're not going to be able to agree on adding both, so they are alternatives.
>>> 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 think you're seeing "aggression" where there is only straightforward
technical disagreement, combined with your own misunderstanding of one of
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 292 bytes
Desc: OpenPGP digital signature
More information about the es-discuss