Small Proposal "!in"

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Small Proposal "!in"

Tobias Buschor-2
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

T.J. Crowder-2
On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Guylian Cox
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 <[hidden email]> a écrit :
On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Cyril Auburtin

```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 <[hidden email]> 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 <[hidden email]> a écrit :
On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Steve Fink
+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 <[hidden email]> 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 <[hidden email]> a écrit :
On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Naveen Chawla
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> a écrit :
On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Jordan Harband
`!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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> a écrit :
On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Naveen Chawla
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> a écrit :
On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

kai zhu
-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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <
>>>>> [hidden email]> a écrit :
>>>>>
>>>>>> On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <
>>>>>> [hidden email]> 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
>>>>>> [hidden email]
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> [hidden email]
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing
>>>> [hidden email]://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Barret Furton
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <
>>>>> [hidden email]> a écrit :
>>>>>
>>>>>> On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <
>>>>>> [hidden email]> 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
>>>>>> [hidden email]
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> [hidden email]
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing
>>>> [hidden email]://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Guylian Cox
It isn't that different from mixing == with ! to get !=

Le mer. 11 juil. 2018 à 15:51, Barret Furton <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <
>>>>> [hidden email]> a écrit :
>>>>>
>>>>>> On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <
>>>>>> [hidden email]> 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
>>>>>> [hidden email]
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> [hidden email]
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing
>>>> [hidden email]://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Barret Furton
Good point.

On Wed, Jul 11, 2018 at 10:02 AM Guylian Cox <[hidden email]> wrote:
It isn't that different from mixing == with ! to get !=

Le mer. 11 juil. 2018 à 15:51, Barret Furton <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]> 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 <
>>>>> [hidden email]> a écrit :
>>>>>
>>>>>> On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <
>>>>>> [hidden email]> 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
>>>>>> [hidden email]
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> [hidden email]
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing
>>>> [hidden email]://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Andrea Giammarchi-2
In reply to this post by Jordan Harband
and, as previously mentioned, `!obj.x` might have side effects through the accessor, as example in every lazily defined property that would be early defined (or anything else behind a getter that could do more than just telling the property is there and it's not truthy).

I have mixed feelings about `!in` and I also wonder if something like `const not = $ => !$;` would make checks look nicer: `if (not('x' in obj)) { ... }`

but that's not really a syntax shortcut, isn't it? Probably a `ni` would be better, as new *not in* relational operator? I wouldn't like `notIn` or `notin` much, but I might use it anyway.



On Tue, Jul 10, 2018 at 6:14 AM Jordan Harband <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> a écrit :
On Thu, Jun 28, 2018 at 5:14 PM, Tobias Buschor <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Alex Vincent
In reply to this post by Tobias Buschor-2
---------- Forwarded message ----------
From: Andrea Giammarchi <[hidden email]>
To: Jordan Harband <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Bcc: 
Date: Wed, 11 Jul 2018 16:23:03 +0200
Subject: Re: Small Proposal "!in"
and, as previously mentioned, `!obj.x` might have side effects through the accessor, as example in every lazily defined property that would be early defined (or anything else behind a getter that could do more than just telling the property is there and it's not truthy).

Peanut gallery observation: I personally think !in is a Really Bad Idea, or at least I'm not convinced that it's particularly useful.  If it is useful, then let one of the transpiling languages like CoffeeScript or TypeScript demonstrate it first.

Also, there's the little matter of pronunciation.  I admit to a bit of snarkiness when I first saw this proposal, but I didn't expect it to have any traction.  So I'll just say it:  do we really want JavaScript to be a "bangin' " language?

Alex

--
"The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Ben Wiley
I find the juxtaposition of a symbol operator against an English operator a bit odd, but I think most English speakers pronounce "!" as "not" so you might not have so much to worry about..

Le mer. 11 juill. 2018 11 h 24, Alex Vincent <[hidden email]> a écrit :
---------- Forwarded message ----------
From: Andrea Giammarchi <[hidden email]>
To: Jordan Harband <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Bcc: 
Date: Wed, 11 Jul 2018 16:23:03 +0200
Subject: Re: Small Proposal "!in"
and, as previously mentioned, `!obj.x` might have side effects through the accessor, as example in every lazily defined property that would be early defined (or anything else behind a getter that could do more than just telling the property is there and it's not truthy).

Peanut gallery observation: I personally think !in is a Really Bad Idea, or at least I'm not convinced that it's particularly useful.  If it is useful, then let one of the transpiling languages like CoffeeScript or TypeScript demonstrate it first.

Also, there's the little matter of pronunciation.  I admit to a bit of snarkiness when I first saw this proposal, but I didn't expect it to have any traction.  So I'll just say it:  do we really want JavaScript to be a "bangin' " language?

Alex

--
"The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Alex Vincent
In Linux programming, #!/bin/bash is very commonly the first line of a shell script. In Python, we have #!/bin/python, or #!/bin/perl.  The #! characters are pronounced "she-bang", because # is pronounced "hash" and ! is pronounced "bang". 

On Wed, Jul 11, 2018 at 8:47 AM, Ben Wiley <[hidden email]> wrote:
I find the juxtaposition of a symbol operator against an English operator a bit odd, but I think most English speakers pronounce "!" as "not" so you might not have so much to worry about..

Le mer. 11 juill. 2018 11 h 24, Alex Vincent <[hidden email]> a écrit :
Also, there's the little matter of pronunciation.  I admit to a bit of snarkiness when I first saw this proposal, but I didn't expect it to have any traction.  So I'll just say it:  do we really want JavaScript to be a "bangin' " language?

Alex

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Isiah Meadows-2
In reply to this post by Alex Vincent
Let me compound on that: Kotlin has a `!in` for "not in collection" and `!is` for "not an instance of". I've been using that language quite a bit lately out of necessity (better than Java, and all the other alternatives suck in some way), and those two operators just feel *wrong* to type. It's to the point I'm sometimes coding my way *out* of writing them. (No other feature uses this symbol except for literal logical negation.)

Oh, and as I mentioned before, `key in object` checks the prototype chain, which in my experience is not the thing you usually want to do.

So I agree this is a Really Bad Idea™, for this above if not the Kotlin reference.

On Wed, Jul 11, 2018, 11:24 Alex Vincent <[hidden email]> wrote:
---------- Forwarded message ----------
From: Andrea Giammarchi <[hidden email]>
To: Jordan Harband <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Bcc: 
Date: Wed, 11 Jul 2018 16:23:03 +0200
Subject: Re: Small Proposal "!in"
and, as previously mentioned, `!obj.x` might have side effects through the accessor, as example in every lazily defined property that would be early defined (or anything else behind a getter that could do more than just telling the property is there and it's not truthy).

Peanut gallery observation: I personally think !in is a Really Bad Idea, or at least I'm not convinced that it's particularly useful.  If it is useful, then let one of the transpiling languages like CoffeeScript or TypeScript demonstrate it first.

Also, there's the little matter of pronunciation.  I admit to a bit of snarkiness when I first saw this proposal, but I didn't expect it to have any traction.  So I'll just say it:  do we really want JavaScript to be a "bangin' " language?

Alex

--
"The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

T.J. Crowder-2
On Wed, Jul 11, 2018 at 4:51 PM, Alex Vincent <[hidden email]> wrote:
> In Linux programming, #!/bin/bash is very commonly the first line of a shell
> script. In Python, we have #!/bin/python, or #!/bin/perl.  The #! characters
> are pronounced "she-bang", because # is pronounced "hash" and ! is
> pronounced "bang". 

Indeed. But in JavaScript (and Java and C and C# and...), `!` is "not", and I for one read it that way when reading anything other than bash script. I don't read `!==` as "bang equal," either. (Which in British English would be really misleading...)

And that's why I like the idea of `!in` (or `notin`), because I'd much rather read and write "if property not in object" than "if not property in object" (and don't get me started on the parens required to make it work :-) ).

To me, `!in` or `notin` or whatever you want makes perfect sense, just like we have `!=` and `!==`. It's like not having `!==` and then arguing we don't need to have it because after all, you can write `n != 1` as `!(n == 1)`.

Heck, all we really need is NAND gates, right? ;-)

On Wed, Jul 11, 2018 at 6:33 PM, Isiah Meadows <[hidden email]> wrote:
> So I agree this is a Really Bad Idea™, for this above if not the Kotlin
> reference.

I strongly disagree it's a Really Bad Idea™. I think it's a Moderately Good Idea On The Whole. And `!in` is fine by me but I'm also happy with `notin` or whatever.

I just don't expect it to happen. Too much inertia to add it after-the-fact, and too many bigger fish to fry. :-)

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Mike Samuel


On Wed, Jul 11, 2018 at 1:51 PM T.J. Crowder <[hidden email]> wrote:
On Wed, Jul 11, 2018 at 4:51 PM, Alex Vincent <[hidden email]> wrote:
> In Linux programming, #!/bin/bash is very commonly the first line of a shell
> script. In Python, we have #!/bin/python, or #!/bin/perl.  The #! characters
> are pronounced "she-bang", because # is pronounced "hash" and ! is
> pronounced "bang". 

Indeed. But in JavaScript (and Java and C and C# and...), `!` is "not", and I for one read it that way when reading anything other than bash script. I don't read `!==` as "bang equal," either. (Which in British English would be really misleading...)

And that's why I like the idea of `!in` (or `notin`), because I'd much rather read and write "if property not in object" than "if not property in object" (and don't get me started on the parens required to make it work :-) ).

To me, `!in` or `notin` or whatever you want makes perfect sense, just like we have `!=` and `!==`. It's like not having `!==` and then arguing we don't need to have it because after all, you can write `n != 1` as `!(n == 1)`.
 
Heck, all we really need is NAND gates, right? ;-)



 
On Wed, Jul 11, 2018 at 6:33 PM, Isiah Meadows <[hidden email]> wrote:
> So I agree this is a Really Bad Idea™, for this above if not the Kotlin
> reference.

I strongly disagree it's a Really Bad Idea™. I think it's a Moderately Good Idea On The Whole. And `!in` is fine by me but I'm also happy with `notin` or whatever.

I agree with all your arguments about why it's more ergonomic, but I keep coming back to what Naveen said: "I don't use `in`."

I think `in` is the wrong operator to make more convenient, except as part of a more general cleanup to provide inverted forms of boolean infix operators.

Usually, where I see `in` I would prefer that the author had used hasOwnProperty.
And usually where I see (foo.hasOwnProperty(p)), I would prefer the author wrote Reflect.apply(hasOwnProperty, foo, [p]).

What are the use cases for `in` that would not be better served by an ergonomic, infix hasOwnProperty?


I just don't expect it to happen. Too much inertia to add it after-the-fact, and too many bigger fish to fry. :-)
 
-- T.J. Crowder
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Small Proposal "!in"

Alexander Craggs
This may be a silly idea that doesn't come naturally to others, but the
first thing I thought of was "!n", where the "!" represents a flipped
"i", so the inverse of in.

Although, on the discussion of "notin" or "!in", the latter comes far
more naturally to me as others have mentioned.

On 2018-07-11 12:27, Mike Samuel wrote:

> On Wed, Jul 11, 2018 at 1:51 PM T.J. Crowder
> <[hidden email]> wrote:
>
>> On Wed, Jul 11, 2018 at 4:51 PM, Alex Vincent <[hidden email]>
>> wrote:
>>> In Linux programming, #!/bin/bash is very commonly the first line
>> of a shell
>>> script. In Python, we have #!/bin/python, or #!/bin/perl.  The #!
>> characters
>>> are pronounced "she-bang", because # is pronounced "hash" and ! is
>>> pronounced "bang".
>>
>> Indeed. But in JavaScript (and Java and C and C# and...), `!` is
>> "not", and I for one read it that way when reading anything other
>> than bash script. I don't read `!==` as "bang equal," either. (Which
>> in British English would be really misleading...)
>>
>> And that's why I like the idea of `!in` (or `notin`), because I'd
>> much rather read and write "if property not in object" than "if not
>> property in object" (and don't get me started on the parens required
>> to make it work :-) ).
>>
>> To me, `!in` or `notin` or whatever you want makes perfect sense,
>> just like we have `!=` and `!==`. It's like not having `!==` and
>> then arguing we don't need to have it because after all, you can
>> write `n != 1` as `!(n == 1)`.
>
>> Heck, all we really need is NAND gates, right? ;-)
>
>> On Wed, Jul 11, 2018 at 6:33 PM, Isiah Meadows
>> <[hidden email]> wrote:
>>> So I agree this is a Really Bad Idea™, for this above if not the
>> Kotlin
>>> reference.
>>
>> I strongly disagree it's a Really Bad Idea™. I think it's a
>> Moderately Good Idea On The Whole™. And `!in` is fine by me but
>> I'm also happy with `notin` or whatever.
>
> I agree with all your arguments about why it's more ergonomic, but I
> keep coming back to what Naveen said: "I don't use `in`."
>
> I think `in` is the wrong operator to make more convenient, except as
> part of a more general cleanup to provide inverted forms of boolean
> infix operators.
>
> Usually, where I see `in` I would prefer that the author had used
> hasOwnProperty.
> And usually where I see (foo.hasOwnProperty(p)), I would prefer the
> author wrote Reflect.apply(hasOwnProperty, foo, [p]).
>
> What are the use cases for `in` that would not be better served by an
> ergonomic, infix hasOwnProperty?
>
>> I just don't expect it to happen. Too much inertia to add it
>> after-the-fact, and too many bigger fish to fry. :-)
>
>> -- T.J. Crowder _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss