Make OAuth 2 decorator compatible with PHP 8.4

[sveldhuisen]

Fix PHP 8.4 deprecation: Implicitly marking parameter as nullable is deprecated, the explicit nullable type must be used instead

[BenjaminFavre]

Thank you for your contribution !
Would you make it pass all the checks please ?

[sveldhuisen]

You're welcome! Those build failures are not related to my code change, but I'll take a look at it once I have some free time available. It seems your repo needs some TLC as it has been a while since the build properties and dependencies were updated. Met vriendelijke groeten,

…

-- Sebastiaan Veldhuisen I D F o c u s b.v. Empowering Identity E: ***@***.*** T: +31 6 1044 3347 W: www.idfocus.nl Aanwezig: maandag - dinsdag - donderdag - vrijdag

On 25 Mar 2025, at 16:10, Benjamin Favre ***@***.***> wrote: BenjaminFavre left a comment (BenjaminFavre/oauth2-http-client#14) Thank you for your contribution ! Would you make it pass all the checks please ? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread. <#14 (comment)> <https://github.com/notifications/unsubscribe-auth/AELPGPG6QHP2JPLCTRUSHS32WFPURAVCNFSM6AAAAABYZZRSKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJRGU4TOMBTGI> BenjaminFavre left a comment (BenjaminFavre/oauth2-http-client#14) <#14 (comment)> Thank you for your contribution ! Would you make it pass all the checks please ? — Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AELPGPG6QHP2JPLCTRUSHS32WFPURAVCNFSM6AAAAABYZZRSKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJRGU4TOMBTGI>. You are receiving this because you authored the thread.

[sveldhuisen]

Psalm validation errors are now fixed: we have a green light >8-)

[sveldhuisen]

@BenjaminFavre : are you ok with approving the outstanding workflow?

[BenjaminFavre]

Hi @sveldhuisen,

Sorry, I've been busy. Thank you again for your contribution!

May I suggest a last update please ?
I am not sure it is a good idea to make the classes final.
I don't think it is necessary, and it may prevent sound extensions.

Unless you argue otherwise, I would be pleased to merge your code this week if you remove the finals.
I guess you will have to tell Psalm not to complain about it.

Thank you again!

[sveldhuisen]

Hi @BenjaminFavre,

Hi @sveldhuisen,

Sorry, I've been busy. Thank you again for your contribution!

No problem, it's been quiet from my side of the pond too >8-)

May I suggest a last update please ? I am not sure it is a good idea to make the classes final. I don't think it is necessary, and it may prevent sound extensions.

As always, it is a matter of opinions. I always make my classes Final, unless I really want to explicitly allow extensions by others. As this is a strict implementation of the oAuth 2.0 RFC I'm not sure why somebody else should be able to extend those classes?

But please enlighten me on some use cases for extensions: maybe I'm overlooking some application to extend those classes.

Unless you argue otherwise, I would be pleased to merge your code this week if you remove the finals. I guess you will have to tell Psalm not to complain about it.

Great! I'm more than happy to remove those finals.

Thank you again!

You're welcome!

[BenjaminFavre]

But please enlighten me on some use cases for extensions: maybe I'm overlooking some application to extend those classes.

I can see one specific reason and one general reason not to make those classes final.

The specific reason is that, you are right, this is an implementation of a standard, though from my experience, sadly, there is a lot of sloppy server implementations of the protocol, and the need to depart from the standard arise quite often.

The general reason is that, although I cannot think right now of a precise good case where someone would like to extend those classes, from my experience, someday, someone will find one, and it is very frustrating when the need arise and the lib closed the possibility.

Finally, beside those potential downsides, I cannot see any benefits to make those classes final.
Unless you think of real benefits to make the classes final that I have overlooked, if the decision has to be taken solely on habitus and preferences, then as the owner of the repo I would prefer without final classes :)

Thank you again!

[sveldhuisen]

As far as I'm concerned it's completely clear: thanks for your explanation.

I don't want to sound stubborn, but it helps me personally to understand the trade-off better if I know what the underlying thought process is. In that way, my own code also evolves in a positive way.

I'll revert the finals!