Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[TypeInfo] AddExplicitStringType andClassLikeStringType classes to hold specific type details forstring builtin types#59833

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed

Conversation

DerManoMann
Copy link
Contributor

QA
Branch?7.3
Bug fix?no
New feature?yes
Deprecations?no
Issues
LicenseMIT

AddExplicitStringType which holds the explicit type forstring builtin types.
Also addsClassLikeStringType which in addition holds the associatedObjectType for class like strings that contain a class name, for exampleclass-string<FooBar>

@mtarld
Copy link
Contributor

Thinking about it once again, I really wonder if we need to deal with all "PHPStan specific" types in Symfony.

I understand that it can exist use cases, but I'm afraid to re-do a PHPStan in Symfony. Implementing all the types ofhttps://phpstan.org/writing-php-code/phpdoc-types looks like a bad idea to me. IMHO, Symfony needs to understandstructural information of types, but knowing that a string is escaped, or an integer is between a specific range is not needed often enough. WDYT?

(The same applies to#59676)

@chalasr
Copy link
Member

chalasr commentedFeb 24, 2025
edited
Loading

I tend to agree this goes beyond type-info’s scope.

@stof
Copy link
Member

I also agree.

Thus, the more complex our types become, the harder it becomes to define the API (see the phpstan type API).
If a project needs the full power of the phpstan type representation, they can depend on phpstan.

@DerManoMann
Copy link
ContributorAuthor

Fine. I'll close both PRs. I suppose this means#59827 will also not happen...

@mtarld
Copy link
Contributor

The array shape type is only one that is worth being merged in my opinion, as it is astructural and widely used type, such aslist<foo> oriterable<bar>, which are already implemented.

@mtarld
Copy link
Contributor

Again thanks for having tried that, and for the great work here@DerManoMann 🙂

@DerManoMann
Copy link
ContributorAuthor

Just for the record - I've started moving my changes into a separate repo. Not ideal as it means forking at least theStringTypeResolver 🤷

https://github.com/DerManoMann/type-info-extras

Any issues around license, etc. let me know as they are not intentional.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@dunglasdunglasAwaiting requested review from dunglasdunglas is a code owner

Assignees
No one assigned
Projects
None yet
Milestone
7.3
Development

Successfully merging this pull request may close these issues.

5 participants
@DerManoMann@mtarld@chalasr@stof@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp