> Throwing another operator name out there: what about `obj has "foo"` instead?
As someone who has just been casually following this issue, I'd much prefer `has` over `on`. I was going to stay quiet, but only because I didn't have a better alternative. jhpratt On Thu, Jul 19, 2018 at 8:56 PM, Isiah Meadows <[email protected]> wrote: > > "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 > [email protected] > www.isiahmeadows.com > > > On Thu, Jul 19, 2018 at 1:03 PM, Mike Samuel <[email protected]> wrote: > > > > > > On Thu, Jul 19, 2018 at 11:56 AM Michael Theriot > > <[email protected]> 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 > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > _______________________________________________ > 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
