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

Improve type inference for stateful container implementations #210

Merged
merged 4 commits into from
Jul 20, 2023

Conversation

gsteel
Copy link
Member

@gsteel gsteel commented Jul 19, 2023

Adds templates to the container and abstract placeholder view helper classes and documents the types used by each implementing view helper.

A lot of incorrect docblocks have been fixed, additional magic methods documented and a decent reduction in the baseline.

Several implementations store values as plain objects and were in places (parameter) type hinting on stdClass. All references to stdClass have been replaced with object and instanceof conditions replaced with is_object. There's no BC break because object is more general than stdClass. The main purpose here is that it's not possible to express object shapes with stdClass which is central to the significant improvements in type inference.

Methods that expect stdClass have been annotated to accept object{foo:string} which results in a lot fewer psalm issues and better inference than the handful of ArgumentTypeCoercion and MismatchingDocblockParamType added to the baseline.

Various public and protected methods have been marked @internal so that they can be made private in the next major, and there are a handful of deprecations for unused, un-documented and un-tested public methods.

Adds templates to the container and abstract placeholder view helper classes and documents the types used by each implementing view helper.

A lot of incorrect docblocks have been fixed, additional magic methods documented and a decent reduction in the baseline.

Several implementations store values as plain objects and were in places (parameter) type hinting on `stdClass`. All references to `stdClass` have been replaced with `object` and `instanceof` conditions replaced with `is_object`. There's no BC break because `object` is more general than `stdClass`. The main purpose here is that it's not possible to express object shapes with `stdClass` which is central to the significant improvements in type inference.

Various public and protected methods have been marked `@internal` so that they can be made private in the next major, and there are a handful of deprecations for unused, un-documented and un-tested public methods.

Signed-off-by: George Steel <george@net-glue.co.uk>
Copy link
Member

@Ocramius Ocramius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only did a quick skim as I'm on the road, soz

src/Helper/HeadLink.php Show resolved Hide resolved
src/Helper/HeadLink.php Outdated Show resolved Hide resolved
Comment on lines -387 to +393
* @return stdClass|false Returns false if stylesheet is a duplicate
* @return object|false Returns false if stylesheet is a duplicate
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO we should hold this back a bit - this change is potentially breaking

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a deprecated, undocumented and internally unused method and it still actually returns a stdClass. For HeadLink specifically, the internal type is just (object) array<string, mixed>, in other implementations, documented return types have been changed to Psalm object shapes. I can't see any practical way that BC is broken here.

Returning object here just satisfies the template for TValue.

Can you explain how this might be a BC break?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The expectation downstream is stdClass, not object, heh :D

@gsteel
Copy link
Member Author

gsteel commented Jul 19, 2023

Only did a quick skim as I'm on the road, soz

Thanks for looking at it @Ocramius

gsteel added 2 commits July 19, 2023 20:13
Also further type inference improvements and psalm fixes

Signed-off-by: George Steel <george@net-glue.co.uk>
Signed-off-by: George Steel <george@net-glue.co.uk>
…here possible

Signed-off-by: George Steel <george@net-glue.co.uk>
Copy link
Member

@Ocramius Ocramius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Went through this in more detail: the move from stdClass to object is fine, and stdClass is kept at runtime anyway, so we're OK here, no BC breaks 👍

Thanks @gsteel!

@Ocramius Ocramius self-assigned this Jul 20, 2023
@Ocramius Ocramius merged commit b3ae82d into laminas:2.29.x Jul 20, 2023
@gsteel gsteel deleted the containers branch July 20, 2023 08:58
@Ocramius
Copy link
Member

Nice improvements BTW!

Selection_166

https://shepherd.dev/github/laminas/laminas-view

@FabianKoestring
Copy link
Contributor

Why was @final added to some classes?

@Ocramius
Copy link
Member

@FabianKoestring we'll make many classes final in the next major release, since allowing inheritance everywhere has hurt our maintainability in a very substantial way.

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.

4 participants