It isn't that different from mixing == with ! to get != Le mer. 11 juil. 2018 à 15:51, Barret Furton <barretfur...@gmail.com> a écrit :
> Mixing the semantics of a unary operator with a binary operator seems... > not ideal. > > On Tue, Jul 10, 2018 at 7:23 AM kai zhu <kaizhu...@gmail.com> wrote: > >> -1 >> >> this feature mostly cross-cuts "!obj.hasOwnProperty('foo')". the only >> semantic-difference is "in" will check prototype-chain as jordan >> pointed out (and widely regarded as a bad design-pattern), while >> "hasOwnProperty" [correctly] will not. in every real-world use-case >> i've encountered, hasOwnProperty is what you actually want instead of >> in. and for looping, "Object.keys(obj).forEach(...)" is usually >> faster than "for (key in obj) {...}" (partly because of again, the >> bad-design prototype-chain lookup inherent with "in"). >> >> also, imagine the cognitive-load placed on yourself when debugging >> integration-javascript with a mix of these cross-cutting >> design-patterns: >> >> ```js >> // can you easily spot where the subtle integration-bug is >> // when dealing with code has a mashup of >> // in and hasOwnProperty? >> >> if ('foo' !in obj) { >> ... >> } >> ... >> if (!obj.hasOwnProperty('bar') { >> .... >> } >> ``` >> >> in summary for those who like to adhere to the python/jslint philosopy >> of "there should be one and preferably only one way to do any given >> task": >> 1. for property-checks, "hasOwnProperty" is generally the one-and-only >> correct-way to do it. >> 2. for looping over properties, "Object.keys(obj).forEach(...)" is >> generally the one-and-only correct-way to do it. >> >> following the above 2 guidelines will save you alot of needless >> cognitive-load when doing integration-debugging of web-projects. >> >> -kai >> >> On 7/10/18, Naveen Chawla <naveen.c...@gmail.com> wrote: >> > Good point. I've never needed falsey valid values in my obj/maps yet, so >> > it'll continue to be very rare that I will need to use `in` (and I'll >> > continue to prefer !obj.x when I don't). >> > >> > However, for this proposal I would prefer a new keyword like `notin` >> > instead of `!in`, because the `!` followed by a word normally indicates >> the >> > inverse boolean of a value in other cases, whereas a clean break like >> > `notin` I think seems clearer. Reserved keyword would probably be needed >> > though? >> > >> > On Tue, 10 Jul 2018 at 09:44 Jordan Harband <ljh...@gmail.com> wrote: >> > >> >> `!obj.x` will return true for any falsy property - null, undefined, >> >> positive or negative zero, NaN, and the empty string. `!(x in obj)` >> will >> >> return true only if `x` is not an own property on `obj` nor anything in >> >> its >> >> prototype chain. They are decidedly different tests and they check for >> >> decidedly different things. >> >> >> >> On Mon, Jul 9, 2018 at 9:08 PM, Naveen Chawla <naveen.c...@gmail.com> >> >> wrote: >> >> >> >>> I don't use `in`. >> >>> >> >>> What do I get with `'x' !in obj` or `!(x in obj)` that I don't get >> with >> >>> !obj['x'] ? >> >>> >> >>> Genuinely asking - I don't know what I am missing. >> >>> >> >>> I use obj[x] because I believe it's a more familiar syntax and I >> believe >> >>> I get the same outcome..(?).. >> >>> >> >>> On Mon, 9 Jul 2018 at 22:41 Steve Fink <sph...@gmail.com> wrote: >> >>> >> >>>> +1 from me for !in. It's a surprisingly common nuisance. >> >>>> >> >>>> And I don't care for the !obj.x workaround at all -- even if you can >> >>>> survive the difference in semantics, from a code reading point of >> view >> >>>> this >> >>>> is saying something entirely different. >> >>>> >> >>>> And it is very different semantically. 'x' in obj does >> [[HasProperty]]; >> >>>> obj.x does [[GetProperty]]. With >> >>>> >> >>>> obj = { get x() { print("getter"); return 3; } }; >> >>>> >> >>>> then |"x" in obj| does not print "getter" while |obj.x| does. >> >>>> >> >>>> >> >>>> On 06/29/2018 12:26 AM, Cyril Auburtin wrote: >> >>>> >> >>>> >> >>>> ```js >> >>>> if (!obj.x && !obj.y) { >> >>>> doit() >> >>>> } >> >>>> ``` >> >>>> The cases where they are equal to 0, '', null, undefined shouldn't >> >>>> matter imo, if for example those x and y are numbers, they would be >> >>>> defined, defaulted to 0, and you would test for `!== 0` rather if >> >>>> needed >> >>>> >> >>>> Le jeu. 28 juin 2018 à 18:31, Guylian Cox <guylian...@gmail.com> a >> >>>> écrit : >> >>>> >> >>>>> I agree, it's very annoying to have to write it !(x in y). I've been >> >>>>> wanting this operator for a very, very long time. >> >>>>> >> >>>>> If there is interest for !in, I think !instanceof deserves to be >> >>>>> included too. >> >>>>> >> >>>>> Le jeu. 28 juin 2018 à 18:19, T.J. Crowder < >> >>>>> tj.crow...@farsightsoftware.com> a écrit : >> >>>>> >> >>>>>> On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor < >> >>>>>> tobias.busc...@shwups.ch> 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() >> >>>>>> > } >> >>>>>> >> >>>>>> There's >> >>>>>> >> >>>>>> ```js >> >>>>>> if (!('x' in obj || 'y' in obj)) { >> >>>>>> doit() >> >>>>>> } >> >>>>>> ``` >> >>>>>> >> >>>>>> That said, I've wanted !in many a time, in a minor sort of way... >> >>>>>> >> >>>>>> -- T.J. Crowder >> >>>>>> _______________________________________________ >> >>>>>> es-discuss mailing list >> >>>>>> es-discuss@mozilla.org >> >>>>>> https://mail.mozilla.org/listinfo/es-discuss >> >>>>>> >> >>>>> _______________________________________________ >> >>>>> es-discuss mailing list >> >>>>> es-discuss@mozilla.org >> >>>>> https://mail.mozilla.org/listinfo/es-discuss >> >>>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> es-discuss mailing >> >>>> listes-discuss@mozilla.orghttps:// >> mail.mozilla.org/listinfo/es-discuss >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> es-discuss mailing list >> >>>> es-discuss@mozilla.org >> >>>> https://mail.mozilla.org/listinfo/es-discuss >> >>>> >> >>> >> >>> _______________________________________________ >> >>> es-discuss mailing list >> >>> es-discuss@mozilla.org >> >>> https://mail.mozilla.org/listinfo/es-discuss >> >>> >> >>> >> >> >> > >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss