Closed lhess closed 1 year ago
For reference, I purposefully didn't add the base Uuid class as I was trying to keep feature parity with the normalizer in Symfony's component. Based on what they're testing and https://github.com/symfony/symfony/pull/44721 which deprecates support for the base abstract class in favor of requiring a version-specific sub-class, I'm not sure adding support for the base class is a good idea.
For reference, I purposefully didn't add the base Uuid class as I was trying to keep feature parity with the normalizer in Symfony's component. Based on what they're testing and symfony/symfony#44721 which deprecates support for the base abstract class in favor of requiring a version-specific sub-class, I'm not sure adding support for the base class is a good idea.
The difference here is, that \Symfony\Component\Uid\Uuid
is not abstract. It also valid to use \Symfony\Component\Uid\Uuid
as a lower boundary in an interface: My API does not care which specific UUID version was used to generate an UUID, I only care about that it is an UUID.
The SymfonyUidHandler is lacking support for the
\Symfony\Component\Uid\Uuid
super type that is available since v5.1 of thesymfony/uid
component.Supporting this super type is helpful in situations in which an interface does not care about which exact UUID version is actually used.