-
-
Notifications
You must be signed in to change notification settings - Fork 190
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
#463: psalm-specific type declarations for generic/intersection types of proxies #465
#463: psalm-specific type declarations for generic/intersection types of proxies #465
Conversation
…arations This is an incomplete patch that just serves to display that types can be improved massively in here, making even this magic contraption of a library usable downstream with some decent type constraints.
a PR fixing itself ? That's inception. |
What do you mean by that? I didn't catch the joke XD |
The description contains this:
This reference is the PR itself. |
Ha, fixed, thanks! |
To get everything green, we'll probably need this massive list of issues fixed first: - [x] vimeo/psalm#1673 - [x] vimeo/psalm#1674 - [x] vimeo/psalm#1675 - [ ] vimeo/psalm#1677 - [ ] vimeo/psalm#1679 - [ ] vimeo/psalm#1680 - [ ] vimeo/psalm#1681 - [ ] vimeo/psalm#1682 - [ ] vimeo/psalm#1683
Won't get to fix them anyway, so they are just noise.
…arations This allows for templating `AccessInterceptorValueHolderInterface` directly, and therefore having the same object type for the `ValueHolderInterface` and the `AccessInterceptorInterface` methods. Without this, psalm gets quite confused about what type the factory is supposed to create.
Also applied CS fixes
This is 🔥 |
The `callable` initializer has a different signature for `GhostObject` and `LazyLoadingInterface`, sadly.
Revert this commit when we need to re-introduce phpstan, but until generic/templated types are supported, phpstan is not viable for static analysis for this particular project.
Ok, so my latest changes lead to wild issues in Psalm:
There is no mention of |
Yeah something in examples is polluting stuff - I'll find and fix |
Fixed in vimeo/psalm@0ad5769 |
Type-checks are fine, but only if they reflect the reality of a shitty runtime-based language :-P
Hmm, since latest builds, psalm now fails with something like this on 7.4:
@muglug I just need to pin this to a stable release with a green build, and then I can release here 👍 |
I'll send a patch to fix the EDIT: see vimeo/psalm#1726 |
@Ocramius is just that good. |
Green! Now needs a release upstream and we can 🚢 \o/ |
Will hopefully release later today, barring any major impediments |
Thanks! That should be enough to do a release here, if all is green 🚀 |
Relevant CI tasks are GO! 👍 |
Fixes #463
This is an incomplete patch that just serves to display that types can be
improved massively in here, making even this magic contraption of a library
usable downstream with some decent type constraints.
TODOs:
vimeo/psalm
(^3.4.0
)Blocked by:
Foo&Proxy<Foo>
methods withclass-string<Foo>
vimeo/psalm#1675@psalm-return
intersection type may lead to detectingmixed
instead of correct type vimeo/psalm#1677callable
parameter types becomeobject
when templated vimeo/psalm#1679parent
is erroneously detected asself
vimeo/psalm#1681@psalm-suppress
not picked up on typed property declarations vimeo/psalm#1683class-string<T>
not correctly inferred asclass-string<ConcreteType>
in property assignments vimeo/psalm#1722Fn
toTFn
to allow for PHP 7.4 compatibility vimeo/psalm#1726