You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I started to add jsdoc type annotations to generate-bytecode.js, and found a number of issues that typescript doesn't like. It seemed to make sense to fix those separately. But I can add the actual ts-check pull request (not yet submitted) to this one if you'd prefer.
Using thing | 0 to produce an integer when thing could be undefined
this can be useful in some cases - eg if thing might be boolean, or a non-integer, or an integer outside the range of a 32 bit number. But in every case, it's a match field which is always one of -1, 0, 1 or undefined. So thing || 0 does the same thing, and typescript is happy with it.
Putting null into arrays that are supposed to contain numbers
In every case it was to avoid adding something to one of the literal arrays, when the match field says that it won't be used. So using -1 is just as good.
Using Object.entries with lib set to ES2015
If you think ES2017 is universal enough, we could just bump the lib version. With this diff I've gone with switching to Object.keys.
Last time that we discussed |0, I recall @Mingun having opinions. Typescript's reaction might change their mind.
nod
I think switching to Object.keys is probably better for now, even though it's been 'broken' for long enough that we can probably just switch lib version. I'd like to have a larger discussion about version support after we refactor code generation.
|0 is used only as idiomatic way to convert everything into an integer in JS. In theory, that also should help JIT that will see that the property variable has only integer shape. If something changed since those times, you can refactor code to reflect that.
While I agree that |0 is probably still better, a) Typescript doesn't understand it and b) I don't think this is going to make enough performance difference to matter, so let's move forward.
@markw65 do you want me to merge this now, or would you like to add another commit that turns on ts-check first? (regardless, will need a changelog)
node -p 'const start=Date.now(); let x = 0; for (let i = 0; i < 1000000000; i += (x || 0) + 1) {}; Date.now() - start'
1402
node -p 'const start=Date.now(); let x = 0; for (let i = 0; i < 1000000000; i += (x | 0) + 1) {}; Date.now() - start'
698
Similar results if you start with let x = undefined.
But at an extra 700ms for a billion iterations, I don't think it would be possible to measure the impact on peggy...
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I started to add jsdoc type annotations to generate-bytecode.js, and found a number of issues that typescript doesn't like. It seemed to make sense to fix those separately. But I can add the actual ts-check pull request (not yet submitted) to this one if you'd prefer.
Using
thing | 0to produce an integer when thing could be undefinedmatchfield which is always one of -1, 0, 1 or undefined. Sothing || 0does the same thing, and typescript is happy with it.Putting null into arrays that are supposed to contain numbers
literalarrays, when thematchfield says that it won't be used. So using -1 is just as good.Using
Object.entrieswithlibset toES2015ES2017is universal enough, we could just bump thelibversion. With this diff I've gone with switching toObject.keys.