Re: [RFC] Enumerations, Round 2

From: Date: Thu, 31 Dec 2020 12:53:07 +0000
Subject: Re: [RFC] Enumerations, Round 2
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-112698@lists.php.net to get a copy of this message
On 30/12/2020 21:24, Aleksander Machniak wrote:
My argument is that, from an end-user perspective, I don't really see why Unit and Scalar enums have to have different "API" at this point. I'm talking about ":string"/":int" in the enum definiton as well as ->value and ->from().
My personal opinion is that for many enums, explicitly not having a scalar representation is a good thing. This is basically similar to my opinion of __toString() etc: if you have *multiple* ways to convert something to/from a scalar, blessing one of them as "default" is arbitrary and confusing. For example: enum BookingStatus {
     case PENDING;
     case CONFIRMED;
     case CANCELLED;
     public function getId() {
           return match($this) {
                self::PENDING => 1,
                self::CONFIRMED => 2,
                self::CANCELLED => 3,
           };
     }
     public function getCode() {
           return match($this) {
                self::PENDING => 'PEN',
                self::CONFIRMED => 'CON',
                self::CANCELLED => 'CAN',
           };
     }
     public function getEnglishDescription() {
           return match($this) {
                self::PENDING => 'Pending Payment',
                self::CONFIRMED => 'Confirmed',
                self::CANCELLED => 'Cancelled',
           };
     }
} Regards, -- Rowan Tommins [IMSoP]

Thread (52 messages)

« previous php.internals (#112698) next »