-
-
Notifications
You must be signed in to change notification settings - Fork 132
Added new methods and changed source structure to be PSR4 compatible #5
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
Added new methods and changed source structure to be PSR4 compatible #5
Conversation
danielcosta
commented
Oct 19, 2014
- PSR4 compatible package
- new getKey() method (returns the key of the current value on Enum)
- new keys() method (returns the names (keys) of all constants in the Enum class)
- moved toArray() to values() method (returns all possible values as an array)
- flagged toArray() as deprecated for future removal
- new isValid() static method (check if tested value is valid on enum set)
- new isValidKey() static method (check if tested key is valid on enum set)
- new search() method (return key for searched value)
- PSR4 compatible package - new getKey() method (returns the key of the current value on Enum) - new keys() method (returns the names (keys) of all constants in the Enum class) - moved toArray() to values() method (returns all possible values as an array) - flagged toArray() as deprecated for future removal - new isValid() static method (check if tested value is valid on enum set) - new isValidKey() static method (check if tested key is valid on enum set) - new search() method (return key for searched value)
Hi, thanks for the pull request. This is a very extensive change, the majority of it is welcome though. I'm just not to keen on deprecating The library is so simple, I'm not sure breaking BC (because deprecating obviously means breaking BC in the future) is worth it for just a naming. I understand it will not be consistent with your suggested additions but maybe it would be better to keep |
Yes, I agree with this point of view. What do you think should be better? To keep values() as an alias of toArray(), or remove it and simply keep toArray() method as always it has been? I will then send a new commit to accomplish this. |
@mnapoli @danielcosta excuse my entering the discussion but this PR has been hanging for some time now and these changes are very welcomed. @danielcosta has ironed out mentioned BC breaks and I'd appreciate merging it. I'd like to contribute some more, since me and my team are using this lib heavily but we need this PR in upstream :) |
It would be great to see this merged 👍 |
Merging! Thank you @danielcosta |
Added new methods and changed source structure to be PSR4 compatible
Released in 1.3.0 |