Skip to content
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

Closed
wants to merge 74 commits into from

Conversation

Majkl578
Copy link

@Majkl578 Majkl578 commented Jan 7, 2019

Allowing inheritance of Uuid class is a terribly bad decision and encourages bad design:

  • There is 46 (!) public methods in Uuid class, these implicitly become public API of any descendant.
  • People abuse inheritance to avoid writing few lines of code without thinking of consequences.
  • Composition should be encouraged and even enforced, it shouldn't be _up to the consumer (opposed to " I'll agree with you that I prefer composition over inheritance, but I prefer choice even more so." by @stanlemon in Remove "final" keyword to allow extending #25).
  • The argumentation in [Feature] Make uuid mockable #23 is wrong, Uuid is not supposed to be mocked, it's a value object. Also there is an interface (now).

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

bradynpoulsen and others added 30 commits January 19, 2018 18:29
* 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
… on Ramsey\Uuid\Converter\TimeConverterInterface::calculateTime()
…y RandomLibAdapter::$generator not being type hinted as nullable
@ramsey ramsey added this to the Version 4.0.0 milestone Jan 7, 2019
@Majkl578
Copy link
Author

Majkl578 commented Jan 7, 2019

What actual, existing problems are you solving with this massive BC break?

Can you explain on what grounds this is a massive BC break? For me it's an edge case.

@ramsey
Copy link
Owner

ramsey commented Jan 7, 2019

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

@Ocramius
Copy link
Contributor

Ocramius commented Jan 8, 2019

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 UuidInterface already provides an excellent way to implement alternate UUID variations.

The fact that the boundary was broken means that in userland you have to assume that there may be subtypes to Uuid when type-hinting against the rigid type, which per-se was already a BC break.

@OskarStark
Copy link

Regardless of being a BC break here or not, it can be handled and a new major could be released including final, so existing code will still work.

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").
This is a ValueObject with an interface, which allow mocking very easily if needed (this is often an argument against making a class final), so this should definitely be final.

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

Copy link

@greg0ire greg0ire left a 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?

@Ocramius
Copy link
Contributor

Ocramius commented Jan 8, 2019

Should protected fields and methods become private?

Can be done safely, plus can apply all the optimisations you want now 👍

@unkind
Copy link
Contributor

unkind commented Sep 9, 2019

and UuidInterface already provides an excellent way to implement alternate UUID variations.

By the way, this interface is better to be removed as well. Unnecessary abstraction.

@OskarStark
Copy link

Can we proceed here with a new major?

@ramsey
Copy link
Owner

ramsey commented Sep 9, 2019

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.

@ramsey ramsey changed the base branch from master to 4.x November 30, 2019 05:11
@ramsey ramsey closed this Dec 17, 2019
@ramsey ramsey reopened this Dec 17, 2019
@ramsey
Copy link
Owner

ramsey commented Dec 17, 2019

I just attempted to cherry-pick this commit into the new 4.x branch and realized that it won't work in its current state because DegradedUuid extends Uuid. 🤦‍♂

@ramsey ramsey force-pushed the 4.x branch 5 times, most recently from 21fdb2a to 6498812 Compare December 24, 2019 02:56
@ramsey ramsey force-pushed the 4.x branch 4 times, most recently from 2b156cc to 1c7eba3 Compare January 9, 2020 03:55
@ramsey ramsey force-pushed the 4.x branch 2 times, most recently from 8d3debe to 72a2312 Compare January 18, 2020 18:15
@ramsey ramsey closed this Jan 22, 2020
@Majkl578 Majkl578 deleted the final-again branch January 22, 2020 09:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.