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, >> <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.
That section is clear that it is talking about the syntax proposed in <http://wiki.ecmascript.org/doku.php?id=strawman:names>. (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 value." 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 > <http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names> > 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 > way. 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 > users). 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 > substitutable. 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 the proposals. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
