-
-
Notifications
You must be signed in to change notification settings - Fork 35
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
Update various typing information #196
Conversation
* | ||
* @return Collection<list<mixed>, list<mixed>> | ||
* @param iterable<UKey, U> ...$iterables |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that it's not possible to type this thing as it is a variadic parameter.
I don't know if it's a good idea, but I had the idea to do the typing of only one element, knowing that it would not be completely valid if there are more than one parameters given.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get what you're looking to do here. The only issue is that when a user will try to use it with multiple iterables of different types they will get an error and so think that it's not supposed to be used like that.
I'm not sure how people normally use zip
, maybe it wouldn't be an issue if most often it's used with a single type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I leave this question open as I don't have any idea yet on what is best to do...
Zip
and Associate
typing informationZip
and Associate
typing information
I deleted my previous comment and fixed the issue with PSalm and PHPStan, this is now ready for review. |
5fc373f
to
5b3e278
Compare
Zip
and Associate
typing informationb2be1a7
to
d787b55
Compare
* @template T of array{0: NewTKey, 1: NewT} | ||
* | ||
* @template NewTKey | ||
* @template NewT | ||
* @template T |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't get this change. Was the existing annotation not working? Or is it not correct?
There's no static analysis check for unpack
so this would be the time to add one if we're changing these
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Despite the fact that this was technically valid, I changed that because:
- All operations interfaces are using 2 templates (
TKey
andT
),Unpackable
was using 4 (TKey
,T
,NewTKey
,NewT
) - Incoming templates (
TKey
andT
) should be opaque, at least that's how it works on every other operations. We should not describe the structure of these or else it will never end. If we start to do that, where should we put the limit or depth of details? - By removing that, we can remove a bunch of "unsupported" lines from
phpstan-unsupported-baseline.neon
Regarding the SA for Unpack
, I will add it today for sure!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I reverted the changes, I cannot get through it properly in PHPStan.
* @return Generator<int, T> | ||
* @return Generator<int, T, mixed, void> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does it add to the type information to add the other Generator generics, or were they already inferred as those types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Alex,
I don't understand your question, can you elaborate?
To give you a bit of context, this was spotted by PHPStan when using (see this tweet):
parameters:
checkExplicitMixed: true
This is why I added some of these things here and there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, sounds good! Should we add that in the PHPStan config in a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, not yet, I'll wait the next release of Phpstan before making those changes. I even think that it will be enabled by default in the new level 9 :)
Found those small glitches using PHPStan upcoming features.
248fc9e
to
dafa9b6
Compare
phpstan-unsupported-baseline.neon
Outdated
@@ -20,7 +20,18 @@ parameters: | |||
count: 1 | |||
path: src/Contract/Operation/Unpackable.php | |||
|
|||
- | |||
message: "#^Parameter \\#1 \\$callable of class loophp\\\\collection\\\\Iterator\\\\ClosureIterator constructor expects callable\\(\\.\\.\\.mixed\\)\\: iterable\\<int, string\\>, Closure\\(mixed, bool\\)\\: Generator\\<int, string, mixed, void\\> given\\.$#" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the only part (The 2 new entries in this file) that I cannot fix. If you have any idea, just let me know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's a bit difficult to tell at a glance, but leave this will me I will try to see if I can figure out the problem and fix it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, thanks! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@drupol so after testing I realised this happens when passing a callable which takes multiple parameters, both to the ClosureIterator and the Collection object itself. Why? I'm not entirely sure but see the latest commit and the other comment for the changes I did and let me know if you think that works
Co-authored-by: Alex Gidei <[email protected]>
return new self( | ||
static fn (string $string, string $delimiter): Iterator => new StringIterator($string, $delimiter), | ||
[$string, $delimiter] | ||
); | ||
return new self(static fn (): Iterator => new StringIterator($string, $delimiter)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does it matter if we pass the parameter to the closure or we just let it capture it from the environment? At least with the testing we have it doesn't seem to make any difference, but it fixes a PHPStan error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure technically this is valid, it's just confusing according to me, this is why I made the change.
I wish I could understand why PHPStan doesn't like it.
@drupol thank you for the work on this 👍 |
This PR:
Associate
class is no more variadic - (Minor BC Break - only when using theAssociate
class on its own)Zip
andAssociate
typing informationUnpack
operation and its interface.Associate
documentation/examples has been updated - added more examples.