-
-
Notifications
You must be signed in to change notification settings - Fork 502
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
Make Uuid final again (aka Revert 'Remove "final" keyword to allow extending') #255
Conversation
* Maintain backwards compatibility with the former Uuid::isValid() and Uuid::VALID_PATTERN * Remove the assert statements in favor of str_replace and preg_match * Make the validator a featureset of the factory * Remove old suggestion about locations of constants * Remove argument count assertions * Remove VALID_PATTERN from Uuid
The Docker images currently do not have all the proper dependencies for some newly-updated dependent packages (i.e. iconv), so we're using standard Travis for the moment.
Additionally remove apigen & coveralls and lower version for doctrine/annotations.
It is not necessary anymore, because the minimal required version was already set to 7.0
- Add XSD schema, so it can be validated (and PHPStorm provides auto-completion) - Drop backupGlobals option, because false is the default value
* issues found by phpstan L0 * issues found by phpstan L1 * issues found by phpstan L2 in src/ * issues found by phpstan L2 in tests/
It helps with refactorings and static analysis, because you can easily tell if the class is missing or not.
It was removed from Travis in c479cdd
This reverts commit ad89bda.
… on Ramsey\Uuid\Converter\TimeConverterInterface::calculateTime()
…y phpstan level 3
…ast/math, as mentioned in ramsey#210
…y RandomLibAdapter::$generator not being type hinted as nullable
Can you explain on what grounds this is a massive BC break? For me it's an edge case. |
It’s a BC break for those who might be extending the class to override functionality. My understanding is that there are some who like to inject their own bits into the UUID at certain places. I think the design changes I’m proposing in #256 provide a better path for this, but it does break BC for anyone currently extending |
This is a BC break, but a UUID is a rigid type covered by clear specifications. Subclassing is absolutely NOT the correct way to have alternate UUID types, and The fact that the boundary was broken means that in userland you have to assume that there may be subtypes to |
Regardless of being a BC break here or not, it can be handled and a new major could be released including If I understand @Majkl578 correctly this PR is just about doing it or not (not about "don't do it, it's a BC break"). For me this is more a decision about the future and not the past, closing the API and knowing how its gonna be used is a big plus and will bring more flexibility for further development. I am 👍 //cc @greg0ire |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should protected fields and methods become private?
Can be done safely, plus can apply all the optimisations you want now 👍 |
By the way, this interface is better to be removed as well. Unnecessary abstraction. |
Can we proceed here with a new major? |
This most definitely will be included in a new major version. I have some structural changes I intend to make and have not had time to devote to this, hence the delay. |
I just attempted to cherry-pick this commit into the new |
21fdb2a
to
6498812
Compare
2b156cc
to
1c7eba3
Compare
8d3debe
to
72a2312
Compare
Allowing inheritance of Uuid class is a terribly bad decision and encourages bad design:
More on this topic: https://ocramius.github.io/blog/when-to-declare-classes-final/
As this is a BC break for anyone performing heretical practices, targets next major.
This reverts commit c7daee6 / PR #25.
(The build is failing now, will address that once discussed.)