On 2010-12-21 22:12, Brendan Eich wrote:
On Dec 20, 2010, at 11:05 PM, David-Sarah Hopwood wrote:
Please retain all relevant attribution lines.
Brendan Eich wrote:
The new equivalence under private names would be x[#.id] === x.id.
You said under private names here, but it should actually be
under the syntax proposed for private names. It applies to that
syntax with either the soft fields or private names semantics.
... 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.
Again you seem to be confusing the inherited soft fields proposal with
the *separate* proposal on desugaring the private name syntax to inherited
soft fields.
The matter at hand is how the proposed syntax changes affect the semantic
equivalences of ECMAScript. I argued against the syntax changes (including
those to the square bracket operator) on that basis. Now you seem to be
arguing as though I supported the syntax changes. To be clear, I do not
support the currently proposed change to how square brackets work in JS,
regardless of whether that change is specified on top of the soft fields
semantics or the private names semantics. I know that some people consider
it to be an improvement in usability, and I disagree that it is sufficient
improvement to justify the increase in language complexity. There may be
alternative syntaxes that obtain a similar or better usability
improvement with a smaller increase in complexity; I hope so.
(One thing is clear to me; driving experts like MarkM away from participating
in syntax discussions is not going to help with that. Please reconsider,
Mark.)
Talk about more complex and less explanatory. Yes, if you know about weak
maps and soft fields, then it follows -- that is a bit too circular, too
much assuming the conclusion.
This has absolutely nothing to do with weak maps. We're talking about the
consequences of the syntax changes, on top of either proposal.
[...]
So, what if we want to understand '_._' in terms of existing constructs?
Unfortunately, '#.id' must be primitive; there is nothing else that it
can desugar to because 'private id' does not introduce an ordinary
variable (unlike 'const id_ = SoftField()', say).
SoftField(), #.id -- something new in either case.
sarcasm
Oh, OK, it obviously doesn't matter what we add to the language, it's
all the same. Library abstractions, new syntax, major changes in
semantics, who cares? Something new is something new. Let's just roll
a bunch of dice and pick proposals at random.
/sarcasm
Sheesh. A library class, specified in terms of existing language constructs,
is not the same as a new primitive construct, and does not have the same
consequences for language complexity.
And what's this const id_? A gensym?
A possible convention for naming variables holding private names. It doesn't
matter, you're picking on details.
It's tiresome to argue by special pleading that one extension or
transformation (including generated symbols) is more complex, and less
explanatory, while another is less so, when the judgment is completely
subjective. And the absolutism about how it's *always* better in every
instance to use strong encapsulation is, well, absolutist (i.e., wrong).
I gave clear technical arguments in that post. If you want to disagree with
them, disagree with specific arguments, rather than painting me as an
absolutist. (I'm not.)
We should debate strong vs. weak encapsulation, for sure, and in the other
thread you started (thanks for that). But without absolutes based on
preferences or judgment calls about trade-offs and economics.
Tell you what, I'll debate based on the things I think are important, and
you debate based on the things you think are important. Agreed?
Rather it introduces an element in an entirely new lexically scoped
namespace alongside ordinary variables. This is fundamentally more
complex than id, which is just a stringification of the identifier.
I agree that private x adds complexity to the spec.
Good, that's a start.
To be clear, it's not the syntax itself, but the parallel namespace
introduced by 'private x' that I find problematic in terms of both
specification complexity, and conceptual complexity for programmers.
It adds something to solve a use-case not satisfied by the existing
language. There's (again) a trade-off, since with this new syntax, the
use-cases for private names become more usably expressible.
It isn't at all clear that there aren't alternative syntaxes that would
achieve the usability benefit while not being subject to the criticisms
that have been made of the current syntax proposal. Lasse Reichstein posted
some possibilities (_.#_ or _[#_]). The syntax design space has been barely
explored in the discussion so far.
The fact that the proposal is entangled with that syntax, so that it is
difficult to see
