QA: Add type declarations and refine psalm types

[ADmad]

Q	A
Documentation	no
Bugfix	no
BC Break	no
New Feature	no
RFC	no
QA	yes

Description

Some properties and methods were missing type declarations.

[gsteel]

Thanks for the patch @ADmad but there are a few BC breaks that need reverting

[ADmad]

All these are private properties, shouldn't it be safe to change them?

[BC] CHANGED: Type of property Laminas\Diactoros\RequestTrait#$protocol changed from having no type to string
[BC] CHANGED: Type of property Laminas\Diactoros\RequestTrait#$stream changed from having no type to Psr\Http\Message\StreamInterface
[BC] CHANGED: Type of property Laminas\Diactoros\RequestTrait#$method changed from having no type to string
[BC] CHANGED: Type of property Laminas\Diactoros\RequestTrait#$requestTarget changed from having no type to string|null
[BC] CHANGED: Type of property Laminas\Diactoros\RequestTrait#$uri changed from having no type to Psr\Http\Message\UriInterface
[BC] CHANGED: Type of property Laminas\Diactoros\MessageTrait#$protocol changed from having no type to string
[BC] CHANGED: Type of property Laminas\Diactoros\MessageTrait#$stream changed from having no type to Psr\Http\Message\StreamInterface

Constructors can be changed with impunity, changing the type shouldn't cause any error even if the constructor was overridden in a child class.

[BC] CHANGED: The parameter $data of Laminas\Diactoros\Response\JsonResponse#__construct() changed from no type to mixed

[gsteel]

The change in JsonResponse constructor is fine IMO, but it is a technical BC break, just because PHP lets us change the signature of __construct, it's still part of the public API.

The private property changes to the traits are indeed a BC break if users have re-implemented a property without a type hint: https://3v4l.org/aaQTo - if they were class properties, it'd be fine, so very little of this can go into a 3.x release

[ADmad]

Thank you for the trait example, I'll revert the related changes.

I am still not convinced the constructor change is a BC break :)
The arguments aren't being changed, just the untyped argument is explicitly typed as mixed. I can't think of any practical use case which would generate an error with this change.

[ADmad]

I don't think the test failures are related to the changes in this PR.

[gsteel]

No, but whatever they are, they'll need to be addressed separately 🤔

[gsteel]

See #205

[ADmad]

That's not a "me" problem, so I'll let you guys tackle that :)

[ADmad]

Ping

[froschdesign]

@ADmad

Ping

Please could you explain what you expect?

[ADmad]

@froschdesign I expect the PR to be merged :) I believe I have made the changes as per the feedback. The test failures are unrelated to my changes.

[froschdesign]

@ADmad

The test failures are unrelated to my changes.

Thanks for you response but a fix for the problem is needed before something can merge here. And if another pull request is required beforehand, this one remains open.
Merging this pull request means ready for release, but it is not, because there are still open problems.
Thanks for your understanding!

[ADmad]

Okay, thank you for the explanation.

[ADmad]

With the base branch for the merge being updated CI is green now.

[Xerkus]

Please do a rebase instead of merge to update

[ADmad]

Please do a rebase instead of merge to update

Done