Small Proposal "!in"

[Isiah Meadows]

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

Throwing another operator name out there: what about `obj has "foo"` instead?

Either way, it's a new context-sensitive keyword in a very awkward position.

> * Non-clobbering mass assignment.  Like Object.assign but that doesn't
> overwrite existing properties in the assignee.

Could this be a new built-in function instead? Maybe, `Object.defaults`?

Of course, this is a pretty hard tangent from the original thread.

> Many use cases for hasOwnProperty could be better supported by Map, Set, and
> Object.create(null) including:
> ...
> * Configuration objects.
> * Function options bundles.

Not sure these would work well as maps, since it's far easier to just
use dictionary objects as named arguments. Clojure and Ruby are the
two main languages I know that use hash maps exclusively for named
parameters with any frequency, and that's because map/hash lookup is
as easy as property lookup.

- Java and C++ use builders. (Java separates the two, while C++ merges them.)
- C and Rust use structs.
- JavaScript and Lua use simple untyped objects.
- Kotlin, Scala, Swift, C#, Python, and Objective C use native named
arguments that are resolved internally.
- Even Ruby added sugar to support its common idiomatic use of hashes
as named arguments.

-----

Isiah Meadows
me at isiahmeadows.com
www.isiahmeadows.com


On Thu, Jul 19, 2018 at 1:03 PM, Mike Samuel <mikesamuel at gmail.com> wrote:
>
>
> 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...):
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>