Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112438
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>
Message-ID: <31c9d66b-771a-35ed-1b11-c681bbcc02c3@gmail.com>
Date: Sun, 6 Dec 2020 15:11:47 +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: <CAN2symgz-4BoLMUUyQMRXAzzCBB3nf+p160UJyB0H-LCFThXvw@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 06/12/2020 00:17, Paul Crovella wrote:
>> enum cases have no state
> Unless there's a bit left out from this RFC this is not completely
> true, you've just limited them to annoying ways of working with data,
> e.g. static variables.


I'm not sure what you mean here, but it sounds a bit like you're saying 
there are ways to emulate mutable state, so why bother restricting it?

The point is that since enum cases are singleton objects, any instance 
state would actually be global across the program, which is probably not 
what people would expect.


>> static methods on cases, which without data are exactly the same as normal methods
> This is an argument against instance methods, which you kept, rather
> than static methods, which you didn't. How is this division anything
> but arbitrary?


On a singleton object, instance methods and late static binding are 
equivalent, but instance methods are probably more intuitive, since 
people are more used to writing code like "$this->suit->shape();" than 
"$this->suit::shape();"

I guess both could be supported, but other than more code style 
decisions to make, I can't think of what they'd add.


> Again, what is it particular to enums that necessitates adding these
> inconsistencies to the language? I get that*you*  want to avoid state,
> but how is that an enum thing rather than a you thing?


"Inconsistency" is a straw man here, because these are a brand new 
concept that already does things objects don't do. So let's flip it 
around: do you have any use cases for directly storing state on an enum 
case, remembering that such state would be unavoidably global?

Restricting them will likely make other desirable features easier - for 
instance, how would serialization work:

$a = Suit::Hearts;
$a->setColour(Colour::Pink);
$serialized = serialize($a); // does this serialize the instance state?
$a->setColour(Colour::Purple);
$b = unserialize($serialized);
assert($a === $b); // as discussed elsewhere, this should be true
assert($a->getColour() === $b->getColour());  // are they both pink? 
both purple?


Note that Larry's longer term plan is for "algebraic data types", 
including "tagged unions": https://wiki.php.net/rfc/adts Unlike 
straight-forward enum cases, these are not singletons, and each instance 
has its own associated state.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]