ES6 doesn't need opt-in
herby at mailbox.sk
Tue Jan 10 12:07:22 PST 2012
so I looked up the spec. I never remembered the exact [[Put]], [[Get]]
machinery but now it is obvious that ES has in fact "amalgamate" mental
model of "shared-part always-use-setter-for-assignment having shadowing
default setter" (well, I figured that out before looking at spec by just
reverse engineering actual state, but then I looked up). So, really,
not an error. But so is not the Object.defineProperty that is able to create
own property. Assignment is assignment, setting own property is different,
low-level thing. At least as I see it.
P.S.: I would bet 99% of developers thinks the model is in fact "fallback
delegation". :-/ It is simpler model that works most of the time. Always
write locally, always read locally and then look up the prototype chain.
From: Herby Vojčík
Sent: Tuesday, January 10, 2012 6:39 PM
To: John J Barton
Cc: Mark S. Miller ; Brendan Eich ; es-discuss Steen
Subject: Re: ES6 doesn't need opt-in
So, to sum, either we have "self shared part" mental model, in which foo.x
is shared part of bar.x, but then you _cannot_ have "own" shadowing
preoperties and plain "bar.x = 5" behaviour of current implementations is
or we have "own overlaying properties with property chain search" (which I
dubbed "fallback delegation") mental model, in which bar.x = 5 make perfect
sense, but alas not only in writable foo.x scenario, but every time (even if
foo.x does not exist or if foo.x is read-only), so prohibiting it for
read-only foo.x is inconstitency.
So, we have inconsistency anyway, the question is which one to fix (and I am
pretty sure not the first one).
P.S.: Yes, you can construct a complicated mental model amalgamate, like
"shared part with explicit allowance for per-child-subtree-shadowing". Let
someone like Allen or Brendan tells exactly what is the mental model, then.
It seems none of simple, consistent models of "shared part" or "fallback
delegate" is true.
More information about the es-discuss