Hey!

To help keep things organized, we don't allow "Draft" pull requests. Could you please click the "ready for review" button or close this PR and open a new one when you are done?

Note that a pull request does not have to be "perfect" or "ready for merge" when you first open it. We just want it to be ready for a first review.

Cheers!

Carsonbot

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 6.3 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

This was rejected in the past. I don't have the PR/issue at hand

This was rejected in the past. I don't have the PR/issue at hand

#44211, the issue is linked in the PR description. 🙂

The issue was closed after @lyrixx' assessment that implementing the feature is not worth the effort. A good PR could prove the opposite.

Sorry, I overlooked the referenced issue.

A good PR could prove the opposite.

Sure, go ahead then 👍

This PR contains lots of BC breaks, and so it is a no-go as is. That's one of the reason why @lyrixx assessed that the feature is probably not worth the effort: you did less than half of the effort for now.
Side note: using UnitEnum::$name as fallback for BackedEnum::$value when an enum is not backed does not make sense. Names and values are not the same concept (and this probably indicates a bad integration of enums in the component)

This PR contains lots of BC breaks, and so it is a no-go as is. That's one of the reason why @lyrixx assessed that the feature is probably not worth the effort: you did less than half of the effort for now. Side note: using UnitEnum::$name as fallback for BackedEnum::$value when an enum is not backed does not make sense. Names and values are not the same concept (and this probably indicates a bad integration of enums in the component)

I just opened the PR as draft so nothing is finished for now :) I am sure aware of the BC breaks and most of the tests are failing. So I will have a closer look at the BC concerns.

Regarding the UnitEnum vs BackedEnum case, I have started with UnitEnum as the least common denominator, but realised quick that it requires some custom code in the used Enum which feels a bit clunky. I would suggest using BackedEnum because it's more feasible.