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.) Of course we should all separate syntax (we agree now; mea culpa for not doing my part earlier). But that didn't happen, even on the soft fields side. And the wiki'ed result, particularly the bit quoted above, is what everyone including me on the "private names" "side" (I want to have no side) who was reading the wiki indeed reacted to. 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. /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
