Thanks interesting, I hadn’t realized it was possible to “trap” the in
operator using Proxy. I may be wrong, but I don’t think Proxy is capable of
operating on the prototype chain. Specifically, I don’t think you can
change the behavior of the in operator for all Strings (which I’m sure many
would prefer).
If this Symbol were seriously considered I believe it would expand the
meaning of the in operator as you’re correct, this is definitely not it’s
current intention.
Tom
On Thu, May 9, 2019 at 4:39 PM Claude Pache <claude.pa...@gmail.com> wrote:
>
>
> Le 9 mai 2019 à 20:52, Tom Barrasso <t...@barrasso.me> a écrit :
>
> Like Symbol.hasInstance but for the "in" operator.
> This symbol would work for both native and user-defined objects.
>
> **Example implementation** prototyping native object:
>
> ```js
> String.prototype[Symbol.inObject] =
> function(searchString) {
> return this.includes(searchString)
> }
> ```
>
>
> **Example implementation* *for user-defined object:
>
> ```js
> function range(min, max) => ({
> [Symbol.inObject]: (prop) => {
> return (prop >= min && prop <= max)
> }
> })
> ```
>
>
> **Example usage**:
>
> ```js
> ("foo" in "food") // true
> (14 in range(1, 25)) // true
> ```
>
>
> Those two examples seem to give to the `in` operator a meaning that it was
> not intended to have. The `in` operator is specifically meant to check
> whether a given property exists in a given object.
>
> Also, there already exists a way to customise the behaviour of the `in`
> operator, namely by using a Proxy.
>
> —Claude
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
