Le 1 oct. 2014 à 04:43, Mark S. Miller <[email protected]> a écrit :
>
> I suggest we focus on the override mistake. If we come up with a way of
> fixing it and .contains with one new kernel mechanism, that would be great.
> If we only fix the override mistake, still likely worth it. But if a new
> kernel mechanism only fixes .contains, it likely isn't worth it and we should
> return to #1 or #2.
>
I have thought about the possibility to have an "overridable" state attached to
properties. That state may be implemented as an attribute, or as a mechanism à
la @@unscopables.
(I have noted Brendan's reserve for such a mechanism; still, I think it is
worth to consider how it could work with some details.)
The overridable state modifies the semantics of assignment (o.p = v) in the
following ways (in short, it corrects override "mistakes"):
(1) it is not disallowed to set to a given property if there exists a
nonwritable inherited property of same name.
(2) overwriting a nonenumerable property will make it enumerable (unless the
property is nonconfigurable, of course).
In case it is implemented à la @@unscopables, we could even, in order to
minimise the API surface, decide that @@overridables === @@unscopables.
I expect that the overridable state won't need to be examined very often.
Indeed, consider the following:
o.p = v
o.p = w
If the first assignement succeeds, the implementation doesn't need to check the
overridable state in order to perform the second assignment, because the
property will be (1) writable and (2) either enumerable or nonconfigurable.
—Claude
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
