Small Proposal "!in"

Wed Jul 11 14:05:09 UTC 2018

Good point.

On Wed, Jul 11, 2018 at 10:02 AM Guylian Cox <guyliancox at gmail.com> wrote:

> It isn't that different from mixing == with ! to get !=
>
> Le mer. 11 juil. 2018 à 15:51, Barret Furton <barretfurton at 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 <kaizhu256 at 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.chwl at 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 <ljharb at 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.chwl at 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 <sphink at 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 <guyliancox at 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.crowder at farsightsoftware.com> a écrit :
>>> >>>>>
>>> >>>>>> On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <
>>> >>>>>> tobias.buschor at 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 at mozilla.org
>>> >>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>> >>>>>>
>>> >>>>> _______________________________________________
>>> >>>>> es-discuss mailing list
>>> >>>>> es-discuss at mozilla.org
>>> >>>>> https://mail.mozilla.org/listinfo/es-discuss
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> es-discuss mailing
>>> >>>> listes-discuss at mozilla.orghttps://
>>> mail.mozilla.org/listinfo/es-discuss
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> es-discuss mailing list
>>> >>>> es-discuss at mozilla.org
>>> >>>> https://mail.mozilla.org/listinfo/es-discuss
>>> >>>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> es-discuss mailing list
>>> >>> es-discuss at mozilla.org
>>> >>> https://mail.mozilla.org/listinfo/es-discuss
>>> >>>
>>> >>>
>>> >>
>>> >
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180711/68699d41/attachment.html>