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

Add supplier to EnumClassInfo #7097

Open
wants to merge 5 commits into
base: dev/feature
Choose a base branch
from

Conversation

Fusezion
Copy link
Contributor

@Fusezion Fusezion commented Sep 19, 2024

Description

This PR aims to update the EnumClassInfo with a provided supplier method, this way it's no dependant on the creation of one within the ClassInfo#getSupplier method.

In addition to this change EnumClassInfo parameters were changed to more understandable ones, rather than stopping there I added StringMode support into EnumUtils#toString this change was done mostly for ease of use of developers that may or may not change based off flags, since flags already represented the StringMode I wanted to increase usability in these. Since existing implementations lack the support for it.


Target Minecraft Versions: any
Requirements: none
Related Issues: none

  - removes it from 'ClassInfo#getSupplier'
  - Also renames some things under EnumClassInfo to better reflect
@sovdeeth
Copy link
Member

I'm not against this change but what exactly is the benefit here? Shouldn't users never interact with supplier directly, and only through getSupplier?

@Fusezion
Copy link
Contributor Author

I'm not against this change but what exactly is the benefit here? Shouldn't users never interact with supplier directly, and only through getSupplier?

There is likely no benefit outside of at least understanding where things are taking place, a user shouldn't need to feel a need to add .supplier() to an EnumClassInfo like it was recently in #7086 before being removed once mentioned.

getSupplier should only return a supplier not set a supplier if it's not already set

@sovdeeth
Copy link
Member

I'm not against this change but what exactly is the benefit here? Shouldn't users never interact with supplier directly, and only through getSupplier?

There is likely no benefit outside of at least understanding where things are taking place, a user shouldn't need to feel a need to add .supplier() to an EnumClassInfo like it was recently in #7086 before being removed once mentioned.

getSupplier should only return a supplier not set a supplier if it's not already set

well it's rather beneficial to not have a supplier until it's actually needed, but that's pretty minor
I think you should add the explicit supplier to enumclassinfos but keep the getSupplier method as is
No need to potentially break things for no benefit

@sovdeeth sovdeeth added the enhancement Feature request, an issue about something that could be improved, or a PR improving something. label Sep 19, 2024
Fusezion and others added 3 commits September 21, 2024 13:53
Whoops didn't see this earlier

Co-authored-by: Efy <[email protected]>
 - adds additional annotations to string methods
 - uses enumUtils for toStrings in case it ever changes
 - currently unused but is good for future implementations
@sovdeeth sovdeeth added the feature-ready A PR/issue that has been approved, tested and can be merged/closed in the next feature version. label Sep 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature request, an issue about something that could be improved, or a PR improving something. feature-ready A PR/issue that has been approved, tested and can be merged/closed in the next feature version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants