-
-
Notifications
You must be signed in to change notification settings - Fork 50
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
support psalm scalar types #112
Conversation
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.
In general this looks ok. Thanks for taking the time to create this pr!
I do have a few questions, those are mostly regarding the usage of these types.
Can I use a array-key
as a stand alone type?
/** @param array-key $myParam **/
function test($myParam) {}
Or should it always be part of an array, generic or iterable type?
The trait-string
and callable-string
should extend String_
I think? because they are literally just strings but with a specialized meta type? Maybe we should introduce a special interface for these kind of types. Something like StringLike
(I'm open for better names) which is implemented by String_
, ClassString
, TraitString
and CallableString
I would expect that trait-string
needs some more information like class-string
does? same applies to callable-string
?
Yes, |
src/TypeResolver.php
Outdated
@@ -71,6 +71,7 @@ final class TypeResolver | |||
private $keywords = [ | |||
'string' => Types\String_::class, | |||
'class-string' => Types\ClassString::class, | |||
'trait-string' => Types\TraitString::class, |
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.
What does trait-string
provide that class-string
does not? class-string
is meant to be any class-like fqn.
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.
The goal is not to developp a new feature for PhpDocumentor as much as supporting a notation used by projects out there. If a user has trait-string in his codebase, it's not very useful that we already support class-string
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.
That doesn't answer the question. What is the difference? Why isn't there an interface-trait? Is class-string going to change?
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.
The author said in #111 the goal was to support Psalm's pseudo-types. Here's the list:
https://psalm.dev/docs/annotating_code/type_syntax/scalar_types/
Psalm doesn't support interface-string, so it's not in the list. No change is expected with class-string, trait-string is just a more narrow type that have been created for specific purposes in Psalm
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 think we are missing an interface in this lib. So there might be a small change to class-string. But it should not cause any bc breaks since we will just add the interface.
As said before there was a request to support more of psalms pseudo types. Which makes sense since this lib is reflecting the types in docblocks that people write out there. This library is not providing any functionality regarding the types we support.
Most of the supported pseudo types are just meta information to strings. Which do not even exist in php as a language.
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.
class-string
resolves the fqsen, so it seems like trait-string
should as well.
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, by definition of https://psalm.dev/docs/annotating_code/type_syntax/scalar_types/ trait-string
should not be parameterized like class-string
. I opened a issue vimeo/psalm#3865 to clarify how trait-string
should be used and @orklah has already provided an example https://psalm.dev/r/3bff912a5b
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.
Not everything is about implementing psalm types. Since class-string
is essentially the same as trait-string
, it makes sense that they would behave similar in TypeResolver. That's what I'm saying.
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.
@jaapio How I should name the interface? StringType
or StringableType
?
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.
Just dumping some thoughts here:
-
StaticString
because they are representing a value ofString_
those types are not really a Type. It is aString_
but with a certain value type. -
TypedString
-
StringRepresentation
-
StringType
should be avoided I think, because it implicates that it is a type..
Maybe they should even extend String_
But I was trying to avoid that, because it would open doors for a large inheritance tree. Which I don't like.
I plan on finalizing #113 this evening or the next and I would love it if the newly introduced pseudotypes here would follow the same pattern. What I have tried to model is that PseudoTypes have an underlying type (so for False, that is boolean) and that you can identify them through an interface. By extending them from their original Type; you can still typecheck on Type and on the underlying type. This will match the behaviour that a PseudoType is 2 things at the same time. So for false, it is both False and Boolean at the same time |
PR #113 is merged, which introduces the new Pseudo types. If you can update this PR according to that approach it would be great! Regarding the earlier discussion on removing the |
cc9c760
to
b6a886b
Compare
In the meantime psalm has added more pseudo types. They also added |
9ca72bf
to
e675935
Compare
@jaapio Can you trigger a retry for the github actions? Thanks in advance! |
Done, but looks like it is hanging again 😕 Ha now it is running again |
Everything has run successfully but the profile workflow 🤷 |
Please don't mind too much about that. I will check what is going on. |
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.
Could you also add support for the list<?>
type? It's basically an array<int, ?>
EDIT: oh, it's not actually a scalar, so it may be out of scope of your PR, nevermind then
use phpDocumentor\Reflection\Types\String_; | ||
|
||
/** | ||
* Value Object representing the type 'string'. |
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.
Those comments should be updated with their actual types
A reminder to myself, I need to check this 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.
I'm approving this, Code looks good. I didn't find any bc breaks
resolves #111