Small Proposal "!in"

[Naveen Chawla]

I still prefer truthy checks when logically valid. Otherwise a truthy
check + [any other validity check in the logic]. I find `in` far too quirky
and I'd rather never ever use it.

I think `instanceof` is also a messy pattern. I've always preferred having
an overridden method on the object that performs the necessary logic for
that type, instead of if(x instanceof Y)... I find overridden method based
code shorter at the point of use, and scales to many instances /
permutations for type based logic.

Therefore, I'd rather TC39 let these concepts like `in` and `instanceof`
die quietly, and always focus on the more/most powerful ways of getting
things done first.

On Thu, 19 Jul 2018 at 19:14 T.J. Crowder <tj.crowder at farsightsoftware.com>
wrote:

> On Thu, Jul 19, 2018 at 12:32 PM, Andy Earnshaw
> <andyearnshaw at gmail.com> wrote:
> > Although I support the idea of `!in` (for the same reasons as T.J.
> Crowder
> > mentioned, plus it's useful for duck typing), what some browsers do
> isn't a
> > great argument as modern browsers follow the spec more closely with
> regards
> > to inherited accessors like this and you'd never be able to use `!in`
> for an
> > older browser.
>
> Well, there's transpiling.
>
>
> > `!in` and `!instanceof` would be great additions to the operator sets.
>
> AND, agreeing with Mike Samuel, an ergonomic operator for `hasOwnProperty`
> (that doesn't have the issues of being overridden, not being inherited
> because `Object.prototype` isn't in the object's prototype chain, etc.)
> would be a great addition. I don't see any reason they couldn't all be
> part of the same proposal as they touch the same parts of the spec and
> implementations. And agree that the own property ones would be the more
> useful ones, but there are use cases for both.
>
> The immediate temptation is `hasOwn` and `!hasOwn`. My only concern is
> that their operands would be in the opposite order to `in` and `!in`:
>
> ```js
> const o = Object.create({a: 1});
> o.b = 2;
> console.log("a" in o);     // true
> console.log(o hasOwn "a"); // false
> console.log("b" in o);     // true
> console.log(o hasOwn "b"); // true
> ```
>
> For me, `hasOwn` with the different operand order isn't a problem, but
> others may take a different view. Trying to keep the same order takes us
> down a route like `inOwn` which I can't say I care for.
>
> But I wonder if all of this discussion is useful. If someone *did* take
> the time to work out the naming and do a proper draft proposal, perhaps a
> Babel plugin, is there really any likelihood of someone championing it? I'd
> see these contents:
>
> * `name !in obj`, `name notin obj`, or whatever it gets called
> * `obj hasOwn name`, `name inOwn obj`, or whatever it gets called
> * `obj !hasOwn name`, `name !inOwn obj`, or whatever it gets called
> * `Reflect.hasOwn`, the "own" version of `Reflect.has`
> * `Proxy` trap for `hasOwn` (even if the operator has a different name)
>
> Is there anyone appropriately-placed who can say "Yeah, if someone spends
> the time to investigate this and put together a really proper proposal, I'm
> willing to look at that proposal with an eye toward _possibly_ championing
> it." I mean, if there's a 10% chance or better, it may be worth someone's
> time. If there isn't, then...
>
> -- T.J. Crowder
> _______________________________________________
> 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/20180719/cc8d4124/attachment.html>