Small Proposal "!in"

[Mike Samuel]

On Thu, Jul 19, 2018 at 11:56 AM Michael Theriot <
michael.lee.theriot at gmail.com> wrote:

> 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`.
>>
>
> For what it's worth I was also thinking of an "on" operator when reading
> this message, so this is intuitive to me. I also think that is a separate
> idea to propose though.
>

"on" is a good name.  Agree on separate.



> Of couse the usage of `in` is most of the time is not recommended, but it
>>> has it place.
>>>
>>
>> What places does it have?
>> I remain unconvinced that `in` has significant enough use cases to
>> warrant high-level ergonomics
>> were it being proposed today.
>>
>> It exists, and it'll probably never be removed from the language, but I
>> don't think it should be taught
>> as a good part of the language, and linters should probably flag it.
>>
>
> Maybe a radical thought, but does this not apply to hasOwnProperty? If you
> have strong type management why test for a property? The one case I can
> think of is parsing JSON but I handle that with destructuring. Are there
> significant use cases for it? Should linters flag it?
>

Good questions.
Linters should flag
   x.hasOwnProperty(y)
since if you're unsure whether x has an own property y you're probably
unsure whether x has an own property 'hasOwnProperty'.

IIRC, destructuring traverses prototypes so see caveat about library code
and monkeypatching below.
const { toString: f } = {}
typeof f // 'funciton'

You're right that in the middle of an application an instance's type should
determine whether a property is present.
There are use cases at the periphery.

Use cases in bleeding edge JS include
* As you noted, operations on parsed JSON.  Even if you use revivers to
parse JSON to Maps instead of Objects
  you either need own property checks or Object.setPrototypeOf(parsed,
null) when populating the Map.
* Non-clobbering mass assignment.  Like Object.assign but that doesn't
overwrite existing properties in the assignee.
* Reliable hole detection in arrays: (1 !on [0, , 2])
* Adapters that use naming conventions between JS objects and external
systems, like between database field names and JS property names.
* Distinguishing between user-code-defined properties on a host object like
an HTML element and readonly host properties.

Many use cases for hasOwnProperty could be better supported by Map, Set,
and Object.create(null) including:
* Objects used as lookup tables.
* Lookup tables with special purpose fallback logic like message bundles
that fall back from locale 'aa-BB' to 'aa'.
* Configuration objects.
* Function options bundles.
but idiomatic JS hasn't caught up and some library code has to run on old
interpreters, so a transpiling `on` would be nice.
The last two are mostly an issue in library code that needs to be resilient
when loaded alongside monkeypatched prototypes.

Honorable mention:
* for(...in...) iteration broken
solved by for(...of...):
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180719/b41e1c36/attachment.html>