On 07/12/2020 20:20, Max Semenik wrote:
I myself have tried to draft my proposal athttps://wiki.php.net/rfc/enum_v2 which has aspects both similar and different from yours.
I'm afraid that proposal would be a strong -1 from me, as "fancy constants" are my least favourite type of enum. In particular, this would be a deal-breaker:
Conversion from other types is not checked, thus enums can hold values not covered by their constants.
The main reason I want enums is to make it impossible to represent invalid states, so that they don't have to be accounted for at run-time. Allowing someone to write (Month)13 without an immediate error would completely invalidate that purpose.
* Performance concern: I suspect that most developers will not use the advanced features from this proposal and your future plans much, instead they will want to use it in very simple contexts, e.g. "$order->calculateWeight(Weight::Gross)". Would every such call require an object allocation and initialization? What about comparisons, would expressions like "if ($cardType === Suit::Clubs) ..." require a new object?
As I understand it, Weight::Gross just looks up the same object each time, so no allocation would be needed unless this happened to be the first time you'd mentioned that enum.
Once you have an instance of an object, you're just passing around or comparing a pointer (i.e. an integer) anyway, so I would expect it to have roughly the same performance as passing or comparing a bare integer.
Regards, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
