On 2010-12-22 18:59, Brendan Eich wrote: > On Dec 21, 2010, at 11:58 PM, Brendan Eich wrote: > >>>>> ... which is strictly weaker, more complex, and less explanatory. >>>> >>>> So is a transposed get from an inherited soft field. Soft fields >>>> change the way square brackets work in JS, for Pete's sake! >>> >>> They do not. >> >> Ok, then I'm arguing with someone else on that point. > > Many of us were wondering where my (shared) square brackets change for soft > fields memory came from, and re-reading the numerous wiki pages. Finally we > found what I had recollected in writing the above: > > http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#can_we_subsume_names > > There, after Mark's demurral ("I (MarkM) do not like the sugar proposed > for Names, ..."), is this: > > "If we wish to adopt the same sugar for soft fields instead, then > > private key; ... base[key] ... > > could expand to > > const key = SoftField(); ... key.get(base) .... > > If there are remaining benefits of Names not addressed above, here would be > a good place to list them. If we can come to consensus that soft fields do > subsume Names, then “Name” becomes a possible choice for the name of the > “SoftField” constructor." ----- > > This is clearly pitting soft fields against names in full, including a > change to JS's square bracket syntax as sugar. > > The hedging via "If" and the demurral do not remove this from the soft > fields "side" of the death match I've been decrying, indeed they add to it. > This is making a case for dropping names in full in favor of soft fields in > (mostly -- no dot operator or object literal support) comparable fullness. > > For the record, and in case there's a "next time": I don't think it's good > form to chop up proposals made on the wiki (inherited soft fields, explicit > soft fields, inherited explicit soft fields), put arguments about > orthogonal syntax issues (the demurral even says "orthogonal"), and then > use only some of the pieces to refute someone's argument based on the > entirety of the wiki'ed work and the clear thrust of that work: to get rid > of private names with something that is not a complete replacement. > > It doesn't really matter what one correspondent among many wants (IOW, it's > not "all out you" [or "me"]). The argument is about a shared resource, the > wiki at http://wiki.ecmascript.org/, and the strawman proposals on it that > are advancing a particular idea (soft fields, with variations *and > syntax*), and by doing so are trying to get rid of a different proposal > (private names). > > 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. In that case, soft fields are semantically simpler. This should not in any way preclude also criticising the syntax. If your criticisms of soft fields plus the change to [] depended on the fact that the syntax change was layered on soft fields, then you might have a point. But in fact those criticisms apply to the syntax change regardless of which proposal it is layered on. There was and is no "bait and switch". > 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. -- 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
