search

Nyholm / psr7

A super lightweight PSR-7 implementation
MIT License
1.17k stars 77 forks source link

Why final? #139

Closed leemason closed 4 years ago

leemason commented 4 years ago

I understand the goal of the project is to be compliant with the psr spec, but i dont see why that would enforce your implementations to be final?

Being spec compliant, nothing less and nothing more is perfect for use as a parent class in projects where you want to extend the functionality to include your own little helpers here and there and not have to write your own implementation, or deal with the baggage of implementations that add their own methods outside of the spec.

Is this something you would consider changing?

mahagr commented 4 years ago

You should use decorators instead of extending the classes:

https://github.com/getgrav/grav/tree/develop/system/src/Grav/Framework/Psr7/Traits https://github.com/getgrav/grav/tree/develop/system/src/Grav/Framework/Psr7 (ignore AbstractUri, it's deprecated)

XedinUnknown commented 4 years ago

Thing is, you can't always use decoration to change behaviour in a meaningful way, without re-implementing. In a perfect world, that would be great. But we don't write perfect code, and therefore I feel it is unfair to prevent users from adapting code to their needs. Also, and this is my opinion, making things explicitly final violates OCP.

Nyholm commented 4 years ago

These are excellent questions. This has been discussed in lengths at #31.

I know that this library is forcing people to write good code and not to be lazy. I know that it is frustrating. I have not yet seen an argument based on computer science that show that the classes should not be final.

Also, and this is my opinion, making things explicitly final violates OCP.

I see that this is your opinion. But that opinion has no support in the definition of polymorphic open-closed principle. =)

You have to consider the "module" to be the PSR-7 specification together with this implementation.