Native PHP enums for 3.0

[stof]

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).

[DASPRiD]

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]

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 for DASPRiD\Enum\AbstractEnum). All other things are doable (another thing you could not do is implementing __toString as 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]

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).

I'm not sure if this is really desired.

Unless I misunderstood, this would mean:

• create new code for a transition
• consumers of this lib would still need to do a change
• eventually we would remove the transition code in a future version
• and consumers would have to make another change again

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]

@mfn no. Consumers of the library won't have to change anything at the time of the transition code, unless they use AbstractEnum in type checks (instead of typing against the actual enum), which is unlikely.

the process for them would look like that:

1. upgrade to v3 of the library
2. at their own time, replace usages of the legacy methods with the native enum API (constant-based access)
3. upgrade to v4 of the library where transition code is gone.

[vlakoff]

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]

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]

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

	/** @deprecated use DEFAULT_BYTE_MODE_ENCODING */
	public const DEFAULT_BYTE_MODE_ECODING = self::DEFAULT_BYTE_MODE_ENCODING;

(For the record, the proper DEFAULT_BYTE_MODE_ENCODING name has been available since BaconQrCode v3.0.0, released on 2024‑04‑18.)

(Edit: PR #231 has been opened for this.)

[DASPRiD]

Agreed, that can definitely go away at that point; we should review all deprecated symbols.

[DASPRiD]

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.