Fixing the associativity / precedence of the instanceof operator

Salvador de la Puente González salva at unoyunodiez.com
Mon Aug 25 04:05:33 PDT 2014


Before doing that, I would propose to introduce `not`, `and` and `or` with
fixed associativity or even a `notinstanceof` for that case before changing
the semantics of ! operator. Indeed I think `!object instance of class` is
less readable than !(object instanceof class).


On Mon, Aug 25, 2014 at 1:01 PM, Charles Pick <charles at codemix.com> wrote:

> I agree that this could cause some problems, however, that code has never
> been correct in the first place. It's the equivalent of writing `if (false)
> {...}`. Seems like it's reasonable to fix something if it only has an
> impact on code which is already broken.
>
>
> On Mon, Aug 25, 2014 at 11:56 AM, Till Schneidereit <
> till at tillschneidereit.net> wrote:
>
>> On Mon, Aug 25, 2014 at 12:40 PM, Charles Pick <charles at codemix.com>
>> wrote:
>>
>>> Hello, forgive me if this has come up before, I couldn't find any
>>> discussions via Google.
>>>
>>> One regular, annoying mistake I see people making is combining the `!`
>>> operator with `instanceof`:
>>>
>>>     if (!foo instanceof Foo) { ... }
>>>
>>>
>>> of course, this must be written with extra parentheses:
>>>
>>>     if (!(foo instanceof Foo)) { ... }
>>>
>>>
>>> My question is, why? There are no circumstances where the developer
>>> *intended* to write the first version, it's a typo and will always evaluate
>>> to false, even when using Boolean. Therefore would it be possible to fix
>>> the precedence so that the first version is parsed the same way as the
>>> second?
>>>
>>
>> While I agree that the associativity should be different, changing this
>> won't work: there are probably tens of thousands of websites and node.js
>> scripts and what have you out there that would break, because the rely on
>> the current behavior. (Many of them probably because someone "fixed" the
>> associativity issue by inverting the contents of then and else blocks
>> instead of the condition.) Yes, those sites use somewhat broken code, but
>> users don't care as long as they work.
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140825/e1a11d30/attachment.html>


More information about the es-discuss mailing list