The more I consider the issue, the more I think that the most elegant solution is to complete data properties with an additional "overridable" attribute, whose purpose is to refine the meaning of the "writable" attribute in the manner sketched below (in opposition of having an @@unscopables-like hack). At first glance, I expect that the addition of such an attribute should not trigger much BC issues, but that needs to be examined more closely.
—Claude Le 1 oct. 2014 à 10:47, Domenic Denicola <[email protected]> a écrit : > 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]> 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
