Proposal: Symbol.inObject well-known symbol to customize the "in" operator's behavior

Tom Barrasso tom at barrasso.me
Thu May 9 21:17:21 UTC 2019


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.pache at gmail.com> wrote:

>
>
> Le 9 mai 2019 à 20:52, Tom Barrasso <tom at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190509/33b6db31/attachment-0001.html>


More information about the es-discuss mailing list