-
-
Notifications
You must be signed in to change notification settings - Fork 131
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
Enum instances aren't singletons #8
Comments
Yes that's really something I'd like to have! Maybe a 2.0 version could make the constructor private? Currently there is a "cache" so that But then what about deserialized enums… |
Oh, deserialisation would be an issue :/ Also, I discovered that I may just be able to use |
yep forgot to mention that, I use |
See #43 or adrium/php-enum version 1.5.1 |
What would be the point of singletons? Enums are value objects and value objects equality is not based on identity:
The current implementation of Enum is correct because it contains an |
@shadowhand that's a good point indeed. I think the main "issues" would be practicality (ability to use But this package has worked fine until now without singletons, a 2.0 would create a lot of conflicts downstream for very little gain so I think it's acceptable to keep this on hold unless we find a very good reason to release a v2.0. |
Constructor is public, so it will automatically create new instance. $singletone = MyEnum::{MyEnum::search($value)}(); Not best practice, but it will always create single instance |
@KartaviK see my response above. Enums (as implemented in this package) are value objects, and value objects have equality by state, not by being singletons. |
Creating a new object for each enum usage is memory wasting. Imagine you are fetching a huge amount of rows from the database. High memory usage affects performance in general (e.g. GC). Comparing the other languages implementations you can see that they use the singletons: |
IMO, the way this library instantiates its enum values is a detail of implementation. If you disagree, then this library should clearly state in its description that it relies on the value object definition of object equality. |
I support @githoober. IMO it leads to misunderstanding. Enums and ValueObjects behave differently. Enums (as I showed in a comment above) in most languages represents the set of constants. In turn, ValueObject is a structure that can be instantiated (!) with any set of values for defined parameters. |
I came to a conclusion, that It'll require several BC breaks and would be problematic to implement in this library in the near future. As a result, I have created my own implementation of Enums: The implementation is based on Enumeration Classes and is very close to Java Enums and Python Enums.
|
Please, don't do it (i.e. put enums into singletons). Enums are a value objects, and this is bad idea to have singletons for value object. In normal languages to compare value objects you have to implement |
@fruit thank you for your opinion. As I showed in a comment above, Java and Python use an exactly single object instance to represent Enum value. |
I think it would help to mention in
|
@alexkuc sure that makes sense, feel free to send a PR. |
Ideally,
SomeEnum::Foo()
should always return the same instance ofSomeEnum
, so you can do$someEnumValue1 === SomeEnum::Foo()
instead of$someEnumValue1->getValue() !== SomeEnum::Foo
The text was updated successfully, but these errors were encountered: