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

Update various typing information #196

Merged
merged 10 commits into from
Sep 16, 2021

Conversation

drupol
Copy link
Collaborator

@drupol drupol commented Sep 13, 2021

This PR:

  • The Associate class is no more variadic - (Minor BC Break - only when using the Associate class on its own)
  • Fix Zip and Associate typing information
  • Update Unpack operation and its interface.
  • Has static analysis tests (psalm, phpstan)
  • Associate documentation/examples has been updated - added more examples.

@drupol drupol added the enhancement New feature or request label Sep 13, 2021
@drupol drupol assigned drupol and unassigned drupol Sep 13, 2021
*
* @return Collection<list<mixed>, list<mixed>>
* @param iterable<UKey, U> ...$iterables
Copy link
Collaborator Author

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?

Copy link
Collaborator

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.

Copy link
Collaborator Author

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...

@drupol drupol self-assigned this Sep 13, 2021
@drupol drupol changed the title [SA] Update Zip and Associate typing information Update Zip and Associate typing information Sep 13, 2021
@drupol drupol marked this pull request as ready for review September 13, 2021 17:02
@drupol
Copy link
Collaborator Author

drupol commented Sep 13, 2021

I deleted my previous comment and fixed the issue with PSalm and PHPStan, this is now ready for review.

@drupol drupol force-pushed the sa/fix-minor-operations-typing-information branch from 5fc373f to 5b3e278 Compare September 13, 2021 19:29
@drupol drupol marked this pull request as draft September 13, 2021 19:32
@drupol drupol marked this pull request as ready for review September 13, 2021 20:20
@drupol drupol changed the title Update Zip and Associate typing information Update various typing information Sep 13, 2021
@drupol drupol force-pushed the sa/fix-minor-operations-typing-information branch 2 times, most recently from b2be1a7 to d787b55 Compare September 14, 2021 06:25
* @template T of array{0: NewTKey, 1: NewT}
*
* @template NewTKey
* @template NewT
* @template T
Copy link
Collaborator

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

Copy link
Collaborator Author

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:

  1. All operations interfaces are using 2 templates (TKey and T), Unpackable was using 4 (TKey, T, NewTKey, NewT)
  2. Incoming templates (TKey and T) 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?
  3. 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!

Copy link
Collaborator Author

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>
Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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?

Copy link
Collaborator Author

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 :)

@drupol drupol marked this pull request as draft September 14, 2021 12:48
@drupol drupol force-pushed the sa/fix-minor-operations-typing-information branch from 248fc9e to dafa9b6 Compare September 14, 2021 15:52
@@ -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\\.$#"
Copy link
Collaborator Author

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.

Copy link
Collaborator

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok, thanks! :)

Copy link
Collaborator

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

@drupol drupol marked this pull request as ready for review September 14, 2021 17:04
@drupol drupol removed their assignment Sep 14, 2021
drupol and others added 2 commits September 14, 2021 23:52
Co-authored-by: Alex Gidei <34811569+AlexandruGG@users.noreply.github.com>
Comment on lines -542 to +532
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));
Copy link
Collaborator

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

Copy link
Collaborator Author

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 drupol merged commit ba40bee into master Sep 16, 2021
@drupol drupol deleted the sa/fix-minor-operations-typing-information branch September 16, 2021 06:27
@AlexandruGG
Copy link
Collaborator

@drupol thank you for the work on this 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants