Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123391
Feedback-ID: iea414789:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-480-g515a2f54a-fm-20240515.001-g515a2f54
Precedence: bulk
MIME-Version: 1.0
Message-ID: <039af1e8-668d-4e74-ba26-dca3074a5e9b@betaapp.fastmail.com>
In-Reply-To: <99c30f5d-e2f3-4027-a8fc-b3b9c71fb6d1@scriptfusion.com>
References: <fcb90d5b-ac31-49b5-bf72-ed8654c34053@scriptfusion.com>
 <da922505-5cb3-44ac-916c-fbb7f864707b@app.fastmail.com>
 <99c30f5d-e2f3-4027-a8fc-b3b9c71fb6d1@scriptfusion.com>
Date: Tue, 21 May 2024 19:24:25 -0400
To: "PHP Internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Discussion] Implicitly backed enums
Content-Type: text/plain
From: php@mjec.net (mjec)

On Tue, 2024-05-21 at 18:48 -04:00, Bilge <bilge@scriptfusion.com> wrote:
>  >What would be the downside to having all "basic" enumerations actually 
> being implicitly "backed" enumerations?

I'm not Larry but I see a lot of value in knowing that a unit value was explicitly constructed in code, and where the value cannot originate from a conversion of some input. It is particularly useful when refactoring in a large codebase to know that every way SomeEnum::A can be constructed will contain an explicit reference to that case in code.

The uses you suggest are not without merit, of course! And that's why I'm also grateful for backed enums as an option where they make sense (e.g. for values which are ultimately stored in a database).

mjec