The only use that came to mind was detecting a property descriptor in a
prototype chain. Sure is not a day to day use case, but it's useful when
writing libraries that involve descriptor modifications (decorators, for
example, will largely involve it). Recently I had to get the descriptor of
properties in a potencial deep inheritance (current Object helpers only
return own descriptors), and used the `in` operator to guard the prototype
recursive search.
``` js
const searchRecursivelyPropDescriptor = (obj, prop) =>
!obj
? undefined
: Object.getOwnPropertyDescriptor(obj, prop) ||
searchRecursivelyPropDescriptor(Object.getPrototypeOf(obj), prop);
const getPropertyDescriptor = (obj, prop) =>
prop in obj ? searchRecursivelyPropDescriptor(obj, prop) : undefined;
```
Anyways, we can't simply ignore the operator, if we are getting a
`!instance` and opening precedence to future operators (`!on` or `!hasOwn`)
I don't see any problems with a `!in`. Legacy bad design should not affect
language consistency of new features.
Em qui, 19 de jul de 2018 às 12:07, Mike Samuel <[email protected]>
escreveu:
> On Thu, Jul 19, 2018 at 10:40 AM Augusto Moura <[email protected]>
> wrote:
>
>> 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.
>
> --
Augusto Moura
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
