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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
