Thanks Claude for filling in some of the details in my vague thinking. I guess I/we should try to come up with something more detailed, and see how/if it is able to address Mark's use cases, and how implementable it would be, and how extensively it would help (or not).
I tend to agree with Mark that unless this solves a larger problem, it does not pay its own way just for Array.prototype.contains (and potentially Array.prototype.flatten). From: Claude Pache [mailto:[email protected]] Sent: Wednesday, October 1, 2014 09:36 To: Mark S. Miller Cc: Domenic Denicola; [email protected] Subject: Re: Array.prototype.contains solutions Le 1 oct. 2014 à 04:43, Mark S. Miller <[email protected]<mailto:[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
