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

Consistent naming convention #53

Open
konsumlamm opened this issue Mar 14, 2023 · 4 comments
Open

Consistent naming convention #53

konsumlamm opened this issue Mar 14, 2023 · 4 comments

Comments

@konsumlamm
Copy link

There are some inconsistent function names:

  • Mut vs Mutable
    I don't really have an opinion on which is better, but I slightly prefer Mut, since it's shorter.
  • foldMap vs foldlMap
    I don't think it makes much sense to have l or r in foldMap-like functions, since their point is that the order doesn't matter.

I think we should decide on a convention and then go with that, creating aliases and deprecating the old versions.

@andrewthad
Copy link
Member

Yeah, this ended up inconsistent. If someone puts together a PR, I'd be fine with just changing everything to Mut and making it a major version bump. I don't think an attempt at backwards compatibility is worth it. To my understanding, there isn't a backwards compatible way to rename an associated type family (Mutable).

@chessai
Copy link
Member

chessai commented Mar 14, 2023

Yeah, this ended up inconsistent. If someone puts together a PR, I'd be fine with just changing everything to Mut and making it a major version bump. I don't think an attempt at backwards compatibility is worth it. To my understanding, there isn't a backwards compatible way to rename an associated type family (Mutable).

Seconded

@konsumlamm
Copy link
Author

To be clear, I actually meant the use of Mut in function names, do you mean changing that and the Mutable type family?

@andrewthad
Copy link
Member

Just doing the function names has the nice advantage of being backwards compatible, so I'm fine with that option as well. I had interpreted your request as meaning everything, including the associated type family, but it would be fine to leave it as is since users do not often need to type it out.

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

No branches or pull requests

3 participants