On 04/01/2021 11:15, Markus Fischer wrote:
On 03.01.21 12:01, Mike Schinkel wrote:
So in my perfect world this:
enum BookingStatus {
case PENDING;
case CONFIRMED;
case CANCELLED;
}
Would be equivalent to:
enum BookingStatus {
case PENDING = "PENDING";
case CONFIRMED = "CONFIRMED";
case CANCELLED = "CANCELLED";
}
I'm with Mikes' suggesting here, see also my previous messages [1] [2].
I don't know how to back this up with numbers, but the way I see it
the majority of use cases will have a benefit of being able to
directly use the literal values derived from the lexical ones and the
ability to have custom values is feature next to it.
I would personally be OK with this if it was allowed but opt-in, e.g.
adding the ": string" would default the values in that way, or even
something magic like ": auto".
I'm still not a fan of having values *always* defined, because I want to
be able to pick case labels without worrying about whether they make
sense as values.
For instance, there's a similar maintenance issue to named parameters:
having a default value means if I write "case PENDING;" in v1.0, I can't
change that to "case PENDING='P';" or "case PENDING=1;" in v1.1, in case
somebody is relying on the value being 'PENDING', which was never intended.
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
