Good point. On Wed, Jul 11, 2018 at 10:02 AM Guylian Cox <[email protected]> wrote:
> It isn't that different from mixing == with ! to get != > > Le mer. 11 juil. 2018 à 15:51, Barret Furton <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> >> 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 <[email protected]> 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 <[email protected]> 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 < >>> >>>>> [email protected]> a écrit : >>> >>>>> >>> >>>>>> On Thu, Jun 28, 2018 at 5:14 PM, 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() >>> >>>>>> > } >>> >>>>>> >>> >>>>>> 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 >>> >>>>>> [email protected] >>> >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>> >>>>>> >>> >>>>> _______________________________________________ >>> >>>>> es-discuss mailing list >>> >>>>> [email protected] >>> >>>>> https://mail.mozilla.org/listinfo/es-discuss >>> >>>>> >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> es-discuss mailing >>> >>>> [email protected]:// >>> mail.mozilla.org/listinfo/es-discuss >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> 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 >>> >>> >>> >>> >>> >> >>> > >>> _______________________________________________ >>> 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 >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
