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

Clean up generics for a more consistent naming scheme #33

Closed
wants to merge 1 commit into from
Closed

Clean up generics for a more consistent naming scheme #33

wants to merge 1 commit into from

Conversation

regexident
Copy link
Contributor

@regexident regexident commented Jul 17, 2021

Currently the project uses an inconsistent naming scheme for generic arguments, which this PR aims to unify:

  • K, Key -> Key
  • V1, Val1 -> Value1
  • V2, Val2 -> Value2
  • T1 -> Tuple1
  • T2 -> Tuple2

@regexident
Copy link
Contributor Author

@ecstatic-morse I just rebased the Pr onto master, which should make the diff clearer now.

@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Aug 14, 2021

If anything, we'd want to switch to shorter names: going from Val or V to Value doesn't add any additional information, but it does make parameter lists longer. Same thing for Tuple, which should be either T or something like Prefix/Pfx depending on the context IMO.

Obviously, this is all very subjective, but with a compelling reason to rename everything, I don't think we should merge this. I was waiting to see if #34 (which is based on this PR) was that reason, but I think that PR has a fatal flaw.

@regexident
Copy link
Contributor Author

If anything, we'd want to switch to shorter names: going from Val or V to Value doesn't add any additional information, but it does make parameter lists longer. Same thing for Tuple, which should be either T or something like Prefix/Pfx depending on the context IMO.

I'm not married to the particular naming scheme chosen and would be happy to change it to short names.

Obviously, this is all very subjective, but with a compelling reason to rename everything, I don't think we should merge this.

I'd think that even if arguably cosmetic having a uniform naming scheme makes the project more accessible, no?

I was waiting to see if #34 (which is based on this PR) was that reason, but I think that PR has a fatal flaw.

With #34 dead in the water there's no urgency (on my side) to get this PR merged asap either, so I wouldn't mind waiting for the three currently open PRs to be merged first.

That said feel free to close this, if you don't feel the effort overhead is worth it. No hard feelings.

@regexident regexident closed this Jul 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants