Proposal of return types for Result interface
#6287
Conversation
(╯°□°)╯︵ ┻━┻ |
devnix
force-pushed
the
better-result-types
branch
2 times, most recently
from
2b442be
to
af7fd28
Compare
|
I'm not sure, I want to make any guarantees on possible data types returned by our drivers or middleware, tbh. Database-related PHP extensions have a history of getting more type-aware release after release. And if someone decided to write a piece of middleware that let's say decodes JSON on the fly, why should we forbid that?
I like the proposed |
|
I've added another Now I can take a look at each implementation. In the cases where the types are not guaranteed but we assume that they are correct, should we force the type with |
|
If rearranging code without runtime impact (!) makes the static analysis happy, let's do that. Otherwise annotations are fine. |
devnix
force-pushed
the
better-result-types
branch
from
c02a487
to
bb192ab
Compare
|
I think these changes are correct, if there is any other API I can improve in this PR let me know! I observed some |
|
Not sure what's up with those |
|
Little ping here @derrabus, I think all the requested changes are done, if you want to approve the workflows 😃 |
🫡 |
|
There hasn't been any activity on this pull request in the past 90 days, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days. |
|
I can rebase and solve conflicts, but I don't know if there is interest in merging this pull request, feedback would be welcome 🙂 |
|
Yes, please rebase. |
devnix
force-pushed
the
better-result-types
branch
from
7200468
to
880220a
Compare
|
@devnix the changes look good. Assuming this is no longer a draft, I think there should be fewer commits with better messages… for instance, a short explanation making it more obvious why using Side note: I opened #6395, it should make the weird Codecov comments disappear. |
| @@ -28,6 +28,7 @@ public function __construct(private readonly mixed $statement) | |||
|
|
|||
| public function fetchNumeric(): array|false | |||
| { | |||
| /** @var non-empty-list<mixed>|false $row */ | |||
| $row = @db2_fetch_array($this->statement); | |||
There was a problem hiding this comment.
Can we contribute this upstream to the function stubs of PHPStan and Psalm? Overriding all those return types doesn't feel right.
There was a problem hiding this comment.
I guess you are referring also to db2_fetch_assoc(), pg_fetch_row(), pg_fetch_assoc(), pg_fetch_all(),SQLite3Result::fetchArray(), right? I can open a pull request in both projects. I'll link them below.
devnix
force-pushed
the
better-result-types
branch
from
c42fb8f
to
0e2aead
Compare
|
There hasn't been any activity on this pull request in the past 90 days, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days. |
|
Yup, I'll want to finish a couple of contributions to PHPStan and Psalm first related to this pull request 😄 |
Summary
Taking advantage that the next major version is very near, I thought this could be a good addition (maybe a little too late but I just realized about this part of the API.
This draft contains modifications only on the interface just to get your feedback about the correctness of the types, and if it could be a nice addition for 4.0. Also, there could be a couple more of places that could be better typed, WDYT?