On 07/12/2020 01:00, Paul Crovella wrote:
Instance state being global is a well-known problem with singletons.
Maybe don't use singletons then. Or simply document them as was done
in the RFC. I'd prefer the former since singletons don't seem to buy
much here but problems, though maybe I'm missing something.
Yes, I think you are missing something - or maybe I am, because I
honestly can't picture what it would look like for enums *not* to be
singletons.
Would Suit::Hearts be a constructor, producing a new instance each time,
each with its own state? Would we then overload ===, so that
Suit::Hearts === Suit::Hearts was still true somehow?
> In any case why is static state being (kinda sorta) restricted along
with it?
On the face of it, I agree, static properties could be supported. But
looking at the details of the current proposal, it might actually take
some thought to make them feel natural. As I understand it, each case
acts like a sub-class, which is useful for over-riding instance methods,
but would mean a static property would be defined separately on each case:
enum Suit {
static $data;
case Hearts;
case Spades;
case Clubs;
case Diamonds;
}
Suit::$data = 42;
$mySuit = Suit::Hearts;
var_dump($mySuit::$data); // will not print 42, because
Suit::Hearts::$data is a different property
As Pierre says, the idea of backing enums onto objects is mostly an
implementation detail; their fundamental design is based on how enums
are generally used, and implemented in other languages.
Rather than "objects which are a bit enum-like", it might be useful to
frame them as "enums which are a bit object-like". The primary
consistency needs to be with what people will expect an enum to do.
Backing them onto objects makes it easy to add on any object-like
behaviour that feels useful, but once we've added it, it's much harder
to remove or change if we realise it's causing problems for users, or
getting in the way of other features.
That's why I was asking if you had use cases in mind, because I was
starting from that position: assume they have *no* features, and add the
ones we think are necessary and achievable.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
