Skip to content

[TypeInfo] Add ExplicitStringType and ClassLikeStringType classes to hold specific type details for string 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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from

Conversation

DerManoMann
Copy link
Contributor

Q A
Branch? 7.3
Bug fix? no
New feature? yes
Deprecations? no
Issues
License MIT

Add ExplicitStringType which holds the explicit type for string builtin types.
Also adds ClassLikeStringType which in addition holds the associated ObjectType for class like strings that contain a class name, for example class-string<FooBar>

@mtarld
Copy link
Contributor

mtarld commented Feb 24, 2025

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 of https://phpstan.org/writing-php-code/phpdoc-types looks like a bad idea to me. IMHO, Symfony needs to understand structural 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 commented Feb 24, 2025

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

@stof
Copy link
Member

stof commented Feb 24, 2025

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
Contributor Author

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

@mtarld
Copy link
Contributor

mtarld commented Feb 25, 2025

The array shape type is only one that is worth being merged in my opinion, as it is a structural and widely used type, such as list<foo> or iterable<bar>, which are already implemented.

@mtarld
Copy link
Contributor

mtarld commented Feb 25, 2025

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

@DerManoMann
Copy link
Contributor Author

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

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

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

@DerManoMann DerManoMann deleted the explicit-string-type branch February 26, 2025 03:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants