Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112451
To: internals@lists.php.net
References: <d1c4689e-9120-4e90-837c-a1b3eac63cd6@www.fastmail.com>
 <CAN2symh0kEQRa+1DxRAzJHrdqmQFP2xnjKGd1wmsfU_Lv9rH=A@mail.gmail.com>
 <32277b43-079d-4cd7-a159-8ad555096742@garfieldtech.com>
 <CAN2symgz-4BoLMUUyQMRXAzzCBB3nf+p160UJyB0H-LCFThXvw@mail.gmail.com>
 <31c9d66b-771a-35ed-1b11-c681bbcc02c3@gmail.com>
 <CAN2symjwms40cMu3kx44=iSNn5sZZ1jEGeKxfZmLZrQFjJQouQ@mail.gmail.com>
Message-ID: <b6154319-5795-6022-dc3f-3d1c5484c81e@gmail.com>
Date: Mon, 7 Dec 2020 09:30:27 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <CAN2symjwms40cMu3kx44=iSNn5sZZ1jEGeKxfZmLZrQFjJQouQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Enumerations
From: rowan.collins@gmail.com (Rowan Tommins)

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]