Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

src: add ASCII table constants #18743

Closed
wants to merge 1 commit into from
Closed

src: add ASCII table constants #18743

wants to merge 1 commit into from

Conversation

gideontee
Copy link
Contributor

Since we are refactoring ASCII character values into another
separate file, as in the referred PR. Why not create the entire
ASCII character to values mapping for future reference and
completeness.

Refs: #18654

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

Since we are refactoring ASCII character values into another
separate file, as in the referred PR. Why not create the entire
ASCII character to values mapping for future reference and
completeness.

Refs: #18654
@nodejs-github-bot nodejs-github-bot added the path Issues and PRs related to the path subsystem. label Feb 13, 2018
Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

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

I know there’s been some discussion around whether we should make such a change at all, but I’m not really opposed to it at least. The identifiers should imo be a bit easily understandable, though.

One question straight ahead: Are you willing to backport this to all active release branches (v9.x, v8.x, v6.x) yourself manually? There’s a decent chance that will be necessary.

UPPER_Y: 89,
UPPER_Z: 90,
LBRACK: 91,
BSLASH: 92,
Copy link
Member

Choose a reason for hiding this comment

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

Can you spell out BACKSLASH, NUMBER_SIGN, LEFT_BRACKET etc?

Ideally we’d use something pretty close to the official Unicode identifiers, although those might be a bit too verbose sometimes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure!

Copy link
Member

Choose a reason for hiding this comment

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

I personally also preferred the former more verbose naming with LOWERCASE and UPPERCASE.

@gideontee
Copy link
Contributor Author

I'll definitely be willing to learn how to backport this to all necessary releases.

Copy link
Member

@apapirovski apapirovski left a comment

Choose a reason for hiding this comment

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

I will need to think about this a bit but a bit of feedback to start: there was a specific reason that the previous PR went with CHAR_XYZ convention and it's because using the ASCII namespace will be a good bit slower. That's an extra lookup each time as compared to destructuring into constants.

@starkwang
Copy link
Contributor

I'm not opposed to this PR. But if we really need to do this, I think it is better to move these ASCII constants to a separate file (and a name space), like lib/internal/constants/ascii.js.

CHAR_COLON,
CHAR_QUESTION_MARK,
} = require('internal/constants');
const { ASCII } = require('internal/constants');
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 potential extra lookup and unnecessary churn. It can be simplified by changing the original line 35 to } = require('internal/constants').ASCII;

Due to the name change of the constants it would still be necessary to change the entries here but the extra lookup would be gone.

UPPER_Y: 89,
UPPER_Z: 90,
LBRACK: 91,
BSLASH: 92,
Copy link
Member

Choose a reason for hiding this comment

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

I personally also preferred the former more verbose naming with LOWERCASE and UPPERCASE.

@BridgeAR
Copy link
Member

Right now we have multiple entries that still have constants to be migrated. What I am certain about is that we do not use the whole ASCII table but only a fraction of it. Therefore I would really not like to add the whole table. Instead, I would like to only add the entries when we need them.

Adding the namespace is somewhat the same as we do not have anything besides ASCII right now. As soon as we port something that is not ASCII, I would be for adding namespaces.

@daynin
Copy link
Contributor

daynin commented Feb 13, 2018

I completely agree with @BridgeAR

@gideontee
Copy link
Contributor Author

Alright. In that case, would it be better if I close this PR and let whoever that is refactoring the constants to add entries to the table?

@BridgeAR
Copy link
Member

That would be my preference. I do not know what others think about that.

@devsnek
Copy link
Member

devsnek commented Feb 13, 2018

as long as this file only exists for ascii stuff, maybe internal/ascii.js? generally i think libs tend to keep constants scoped to their own files so a general constants file doesn't make sense named as such.

@BridgeAR
Copy link
Member

I am fine with renaming the constants file to internal/ascii.js but I would like to keep the entries as they are. So the only change should be renaming the file out of my perspective. Keeping the CHAR_ is also expressive where ever they are used.

@BridgeAR
Copy link
Member

BridgeAR commented Mar 2, 2018

This has a lot of conflicts right now and there are still questions about this being the right way to progress or not. @nodejs/collaborators PTAL

@tniessen
Copy link
Member

tniessen commented Mar 3, 2018

Sidenote: Subsystem probably shouldn't be src.

Copy link
Member

@apapirovski apapirovski left a comment

Choose a reason for hiding this comment

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

I'm -1 for several reasons:

  • I don't think we should have the whole ASCII table unless it's needed.

  • Adding a namespace doesn't seem very useful. We might have < 10 chars long-term that are not ASCII. It's unclear what other constants might get added but we should address that when it happens not optimize prematurely.

  • The naming convention here is worse than what exists currently for several reasons: it's less descriptive, some names are unnecessarily shortened and it doesn't lend itself well to being destructured into standalone constants because "ENQ", "US" or "SLASH" are not very clear variable names.

  • The changes to path.js are nothing but churn of variable names.

@benjamingr
Copy link
Member

benjamingr commented Mar 5, 2018

You can't +1 a review in GitHub so I'll write that I mostly agree with @apapirovski

@BridgeAR
Copy link
Member

BridgeAR commented Mar 5, 2018

I am closing this due to the mentioned reasons.

@jiaherrt thanks a lot for your contribution anyway! It is much appreciated.

@BridgeAR BridgeAR closed this Mar 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
path Issues and PRs related to the path subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.