Why is the position parameter in the arrayIncludes method using | instead of || ?

[dorisentomari]

1. line 1

himalaya/src/compat.js

Line 31 in f0b8700

const lookupIndex = position | 0

2. line 2

himalaya/src/compat.js

Line 20 in f0b8700

return str.indexOf(searchString, position || 0) !== -1

so, I cannot understand, why you position | 0 in line 1, and use position || 0 on line 2? I thinking both of them could use position || 0 is corrent.

[lazarljubenovic]

Not sure if this was the intention, but | 0 is a quick way to cast to integer, || 0 is a quick way to make a falsy value into zero.

[dorisentomari]

Not sure if this was the intention, but | 0 is a quick way to cast to integer, || 0 is a quick way to make a falsy value into zero.

Thank you reply me, at first I thought about same with you, but I wonder if it's necessary to think about float number, and the stringIncludes function doesn't think about this, so I think we need not think about float number here.

But, if we use | 0 to cast to int , it's no problem. Maybe I think about it too detail.

Tips: lexer.js's code is too hard, I need more time to learn it. 😂😂😂

[andrejewski]

@Dawnight, @lazarljubenovic is correct about the | 0. This also, back in the day, was a means to say a value was an integer such that it could be validated at compile time for asm.js.

When I added these compat methods, I wanted to be sure that they had the same behavior as the native methods. Looking at the usages of arrayIncludes we don't use position anywhere, nor do we need the explicit NaN handling, so that could be cleaned up. However, these days if we were looking to squeeze out performance, we'd use Array#includes and friends directly.

The lexer module isn't as hard to read/understand as parser in my experiences. Both are complicated, which is mostly combated by having an exhaustive test suite.

Closing as the question has been answered; thanks @lazarljubenovic!