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

support psalm scalar types #112

Merged
merged 3 commits into from
Jul 24, 2021
Merged

support psalm scalar types #112

merged 3 commits into from
Jul 24, 2021

Conversation

smoench
Copy link

@smoench smoench commented Jul 16, 2020

resolves #111

Copy link
Member

@jaapio jaapio left a 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?

tests/unit/Types/ArrayKeyTest.php Outdated Show resolved Hide resolved
@smoench
Copy link
Author

smoench commented Jul 17, 2020

Yes, array-key could be used as a standalone https://psalm.dev/r/746af64896

@@ -71,6 +71,7 @@ final class TypeResolver
private $keywords = [
'string' => Types\String_::class,
'class-string' => Types\ClassString::class,
'trait-string' => Types\TraitString::class,
Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor

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?

Copy link
Contributor

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

Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Author

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

Copy link
Contributor

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.

Copy link
Author

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?

Copy link
Member

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 of String_ those types are not really a Type. It is a String_ 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.

@mvriel
Copy link
Member

mvriel commented Aug 24, 2020

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

@smoench
Copy link
Author

smoench commented Aug 25, 2020

Thanks @mvriel. #113 looks promising. Please ping when the changes are done and merged. I will update this PR.

@jaapio
Copy link
Member

jaapio commented Sep 2, 2020

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 final keyword from String_ to be able to extend it... this will be the way to go for pseudo-types. And will also allow people to implement their own pseudotypes based on strings. Which is ok.

@smoench smoench marked this pull request as ready for review September 18, 2020 07:09
@smoench
Copy link
Author

smoench commented Sep 18, 2020

In the meantime psalm has added more pseudo types. They also added interface-string to class-string pragraph so I read it as it should has the same behaviour.

@smoench
Copy link
Author

smoench commented Sep 25, 2020

@jaapio Can you trigger a retry for the github actions? Thanks in advance!

@jaapio
Copy link
Member

jaapio commented Sep 25, 2020

Done, but looks like it is hanging again 😕

Ha now it is running again

@smoench
Copy link
Author

smoench commented Sep 25, 2020

Everything has run successfully but the profile workflow 🤷

@jaapio
Copy link
Member

jaapio commented Sep 25, 2020

Please don't mind too much about that. I will check what is going on.

@smoench smoench requested a review from jaapio October 7, 2020 06:49
Copy link
Contributor

@orklah orklah left a 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'.
Copy link
Contributor

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

@jaapio
Copy link
Member

jaapio commented Feb 2, 2021

A reminder to myself, I need to check this PR.
Code looks good. Just need to check the impact and BC

Copy link
Member

@jaapio jaapio left a 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

@jaapio jaapio merged commit 550e0fb into phpDocumentor:1.x Jul 24, 2021
@smoench smoench deleted the psalm-types branch July 24, 2021 09:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support more scalar types of psalm
5 participants