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 <[email protected]> wrote: > On Thu, Jul 19, 2018 at 12:32 PM, Andy Earnshaw > <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
