Repository navigation
Native PHP enums for 3.0 #198
Description
PHP 8.1 supports enums natively.
They are not direct replacements for dasprid/enum as they don't support instance properties. However, all usages of properties in this library are for private properties, which could easily be replaced by a getter method using match($this) instead to provide the value currently provided in the protected constant defining the constructor argument for dasprid/enum.
This will require being done in a new major version as not extending DASPRiD\Enum\AbstractEnum anymore is technically a BC break. However, I doubt consumers of the library are using AbstractEnum as type in the code.
To ease migration, it probably make sense to provide (deprecated?) static methods for each case and a name() method returning $this->name, as a BC layer for the current public API (which is the impactful part of consumers of the library if it is removed directly instead of being only deprecated or kept around forever as non-deprecated).
Activity
DASPRiD commentedon Sep 18, 2025
I think it'd be fair to transition to native enums in the next major version. Though this being an internal change mostly, I agree that we could basically mimic the original API and immediately mark it as deprecated.
stof commentedon Sep 18, 2025
The only change that you cannot mimic is the fact that it would not extend
DASPRiD\Enum\AbstractEnum(and so that it would not match type checks forDASPRiD\Enum\AbstractEnum). All other things are doable (another thing you could not do is implementing__toStringas that's forbidden in native enums, but none of the BaconQrCode enums implement it).If you mimic other APIs, it is indeed mostly an internal change (which becomes non-internal once you deprecate the old static method in favor of the native enum API based on constants)
mfn commentedon Sep 18, 2025
I'm not sure if this is really desired.
Unless I misunderstood, this would mean:
Seems more straightforward to me to make a single breaking point with a major version and be done? Also makes it easier for other libs to have a clear migration (thinking about pragmarx/google2fa-larave for example)
stof commentedon Sep 18, 2025
@mfn no. Consumers of the library won't have to change anything at the time of the transition code, unless they use
AbstractEnumin type checks (instead of typing against the actual enum), which is unlikely.the process for them would look like that:
vlakoff commentedon Nov 10, 2025
FYI, this is referenced in MediaWiki's cleanup task: https://phabricator.wikimedia.org/T409679.
+1 for making the switch directly in a new major version.
DASPRiD commentedon Nov 11, 2025
I'd say it's safe to simply go to version 4 directly and get rid of the enum library directly. There's not really any good reason to avoid major version jumps, especially since other development has stalled anyway.
@stof Would you be willing to create a PR for this? Though someone has to look into why current tests are failing though :)
vlakoff commentedon Nov 14, 2025
Just a quick reminder: if a new major version is released, we should take the opportunity to drop this monstrosity:
BaconQrCode/src/Encoder/Encoder.php
Lines 25 to 26 in 1e00ebd
(For the record, the proper
DEFAULT_BYTE_MODE_ENCODINGname has been available since BaconQrCode v3.0.0, released on 2024‑04‑18.)(Edit: PR #231 has been opened for this.)
DASPRiD commentedon Nov 14, 2025
Agreed, that can definitely go away at that point; we should review all deprecated symbols.
feat!: replace dasprid/enum with native PHP enums
DASPRiD commentedon Apr 5, 2026
I prepared a PR for the next major release, replacing the my old Enum completely. I'd love to get some more eyes on that.