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
