Re: [IDEA] allow extending enum
| From: | Rowan Tommins | Date: | Wed, 29 Mar 2023 15:31:49 +0000 |
| Subject: | Re: [IDEA] allow extending enum | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-119775@lists.php.net to get a copy of this message | ||
On Wed, 29 Mar 2023 at 15:26, Rokas Šleinius <rokas.sleinius@gmail.com>
wrote:
> Invoking it must provide a unique ErrorCode.
The concept of "uniqueness" only makes sense within a certain context - the
CMS easily create these two enums:
enum HttpErrorCode: int extends ErrorCode {
case NotFound = 404;
}
enum SQLErrorCode: int extends ErrorCode {
case BadColumnRef = 404;
}
If ECS accepts both HttpErrorCode::NotFound and SQLErrorCode::BadColumnRef,
and looks at the integer value, they will both be 404. Are they still
"unique" in any useful way?
The existing cms has
> to create an enum that will be accepted as
type: ErrorCode.
> [...]
> There is NO special handling for the custom ErrorCode's that the
> users of ECS create.
I don't understand this pair of requirements: if ECS doesn't have handling
based on the value, why does it care what type it is?
If it cares that it can turn it into an integer, it can just request an
integer directly, or an object implementing an appropriate interface:
interface ErrorValueInterface {
public function getCode(): int;
}
From the description given, it seems like enums are sinmply the wrong tool
for the job.
Regards,
--
Rowan Tommins
[IMSoP]