On Thu, 19 Jul 2018 at 14:44 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. > Good point. > > `!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`: > I'm not against this at all. I just think the arguments against `!in` aren't really arguments against it. Adding `!hasOwn` would give even more weight to an `!in` proposal, I think. > 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. > Nor me. I would argue for `on` (`'a' on b`), but that is a huge typo footgun (especially for Colemak users) and maybe isn't clear enough about its semantics. I would argue that operators aren't camel cased in JS though, so `hasown`/`inown`. > > 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... > `!in` and `!instanceof` are low hanging fruit (run the same steps as their counterparts but flip the result), better off in their own proposal. I don't know if you'd find a champion to do it, but I do think a lot of people would find them convenient.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
