-
-
Notifications
You must be signed in to change notification settings - Fork 500
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate Uuid#setFactory()
, use dedicated factories for FieldInterface
and for UUID creation
#326
Comments
After reading through #324, it became clear to me why
I agree, and I'd like to throw it out. This was originally a way to swap out components for testing, and it has grown significantly since introduced. Independent concrete implementations of
I'd like to hear more about this. I'm not familiar with the term "inlining." |
Essentially copy-pasting static code to reduce the overhead from stack frame allocation. In static languages, the compiler does that implicitly, as an optimization. While dependency injection does ease testing in this library, most of it is static code, if you assume only defaults. |
Problem-space
While working on #324, it became evident that the majority of complexity within this library comes from
Uuid#setFactory()
, which completely switches the behavior of the (supposedly)@psalm-pure
operations, as well as the variousUuid::uuid1()
throughUuid::uuid6()
methods.Solution
I suggest deprecating and discouraging usage of
Uuid#setFactory()
andUuid#getFactory()
, as well as deprecating all setters onUuidFactory
itself, so that post-instantiation no internals of it can change.After that, we can drop all this API for
5.0.0
, allowing for major performance and design improvements within the core of the library.Further scope
UuidFactoryInterface
also needs to be split up a bit: there is no need for instantiating specific UUID sub-types unless the user relies on them, so I'd suggest having dedicated API for that, and dedicated API for retrievingFieldsInterface
.FeatureSet
is also extremely bloated: while flexible, it leads to a lot of added complexity for supporting things like GUIDs, while separate independentUuidFactoryInterface
concrete implementations would be better for both clarity and runtime performance.The text was updated successfully, but these errors were encountered: