Skip to content

Conversation

@timotew
Copy link
Contributor

I saw some duplicate validations within internal/encoding.js, so I extracted them out to separate functions.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)

util

@nodejs-github-botnodejs-github-bot added the encoding Issues and PRs related to the TextEncoder and TextDecoder APIs. label Jan 28, 2018
@timotewtimotew changed the title Extract out encoding validation functionsfs: extract out encoding validation functionsJan 28, 2018
@timotewtimotew changed the title fs: extract out encoding validation functionsutil: extract out encoding validation functionsJan 28, 2018
Copy link
Contributor

@cjihrigcjihrig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we go this route, I think validateEnDecoder() should be split into two separate functions.

@jasnell
Copy link
Member

+1 to splitting out validateEncoder() and validateDecoder()

Copy link
Member

@BridgeARBridgeAR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not change the validation or the error messages. Otherwise LG

}

functionvalidateArgument(prop,expected,propName){
if(typeofprop!==expected&&!isArrayBufferView(prop))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not only a extraction but it changes the validation itself as it also validates that the input is not an ArrayBufferView. I would like to keep it as is.

encoding=`${encoding}`;
if(typeofoptions!=='object')
thrownewerrors.Error('ERR_INVALID_ARG_TYPE','options','Object');
validateArgument(options,'object','options');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By combining the check for the type with the second ERR_INVALID_ARG_TYPE argument the error message gets changed. That should not be the case. That applies to all validateArgument calls.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BridgeAR the string type checks error messages is not affected.

}

functionvalidateArgument(prop,expected,propName){
if(typeofprop!==expected.toLowerCase())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using toLowerCase is a performance overhead.

I suggest to either split the validation in two functions or to just keep these validations as they were. You can of course also add a fourth argument.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BridgeAR is this last commit inline with your suggestion?

if(isArrayBuffer(input)){
validateArgumentBuffer(input,'input');

if(isArrayBuffer(input))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This results in a second isArrayBuffer check and is definitely not desirable. Please keep that check as it was before (as in: remove validateArgumentBuffer again).

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok.

@BridgeARBridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jan 31, 2018
@BridgeAR
Copy link
Member

BridgeAR pushed a commit to BridgeAR/node that referenced this pull request Feb 1, 2018
PR-URL: nodejs#18421 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
@BridgeAR
Copy link
Member

Landed in b0b2045

I fixed the commit message while landing (adding the subsystem & shortening it)

@BridgeARBridgeAR closed this Feb 1, 2018
@addaleaxaddaleax removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 4, 2018
MylesBorins pushed a commit that referenced this pull request Feb 20, 2018
PR-URL: #18421 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
PR-URL: #18421 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
MylesBorins pushed a commit that referenced this pull request Feb 21, 2018
PR-URL: #18421 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
@MylesBorinsMylesBorins mentioned this pull request Feb 21, 2018
@MylesBorins
Copy link
Contributor

Should this be backported to v8.x-staging or v6.x-staging? If yes please follow the guide and raise a backport PR, if not let me know or add the dont-land-on label.

MayaLekova pushed a commit to MayaLekova/node that referenced this pull request May 8, 2018
PR-URL: nodejs#18421 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

encodingIssues and PRs related to the TextEncoder and TextDecoder APIs.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@timotew@jasnell@BridgeAR@MylesBorins@cjihrig@addaleax@nodejs-github-bot