On Wed, Jul 18, 2018 at 12:21 PM Michael Theriot < [email protected]> wrote:
> I think it is irrelevant; the operator already exists and I would assume > if you want the negation of it you are using it correctly in the first > place. Otherwise are you not just arguing for its removal altogether? But > to answer your question one case that comes to mind is trapping get/has in > a proxy handler. Why should we assume that only people who consistently use `in` correctly would want the negation? It seems that people who use it incorrectly because they are confused about the precise semantics or don't care might want the negation too. If there are more of the latter then we should not assume what you assume. Proxy handler code is important, but very few developers will ever write a proxy handler over their careers, so this seems like a marginal use case. Besides, Reflect.has is probably a better choice in a proxy handler. I am not arguing for removing `in`. That would break the web. I am just arguing for prioritizing changes that provide features that more closely match the semantics developers typically want over making it more convenient to write code that seems to work in casual testing but has subtly wrong semantics. > On Wednesday, July 18, 2018, Mike Samuel <[email protected]> wrote: > >> >> >> On Wed, Jul 18, 2018 at 11:05 AM Michael Theriot < >> [email protected]> wrote: >> >>> I think `in` and `instanceof` could both benefit from having negated >>> versions. >>> >>> Assuming the developer is using `in` correctly, hasOwnProperty concerns >>> are irrelevant. Either way they would attempt to use !(a in b), not >>> !hasOwnProperty. >>> >> >> Why should we assume the developer is using `in` correctly? >> Apologies if I buried my question at the end. It was, what are the use >> cases for `in` that would not be better served by an ergonomic, infix >> hasOwnProperty? >> >> >> Same reason we don't use... >>> !(a == b) // a != b >>> !(a === b) // a !== b >>> >> >> >>> !(a > b) // a <= b >>> (!(a > b) && !(a == b)) // a < b >>> >> >> I'm not sure this is relevant to your larger point, and I've already >> conceded ergonomics, but >> these last two are not equivalent because NaN is weird. >> >> a = NaN, b = 0 >> [!(a > b), a <= b] // [true, false] >> [!(a > b) && !(a == b), a < b] // [true, false] >> >> >> >> >> >>> On Thursday, June 28, 2018, Tobias Buschor <[email protected]> >>> wrote: >>> >>>> I dont like to write: >>>> if ( !('x' in obj) && !('y' in obj) ) { >>>> doit() >>>> } >>>> >>>> I was even tempted to write it that way: >>>> if ('x' in obj || 'y' in obj) { } else { >>>> doit() >>>> } >>>> >>>> What about a !in operator to write it like this? >>>> if ('x' !in obj && 'y' !in obj) { >>>> doit() >>>> } >>>> >>>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
