As the original author of PropertyInfo, I agree that we need a new, more powerful, TypeInfo component. PHP evolved a lot on this topic since the original release of PropertyInfo, and PropertyInfo is now too limited.

One of my regrets withPropertyInfo\Type is that it didn't try to be in sync with the features introduced in PHP directly.
In my opinion, TypeInfo should be a kind of "polyfill" for new and upcoming features introduced to PHP own'sReflectionType class and should inherit from it.

When/if new features (e.g.: generics) are added to PHP directly, then TypeInfo should deprecate its own equivalent feature and use the builtin one. WDYT?

Extending the PHP classes would mean that we cannot really deprecate things in our API as it would be PHP itself doing changes as well. And it might also create confusion if we create our own subclasses ofReflectionType as most code expectingReflectionType will support only the classes defined in PHP.
Thus, we cannot "polyfill" upcoming features as we have no idea how that feature will define its PHP API in the future.

@stof we can implement the methods with the names we want in our subclass and deprecate them in favor of the official ones when they will be added to PHP.

@dunglas, if I understood well, you'd love to have a type class hierarchy like the following:

classDiagramReflectionNamedType <|-- TypeReflectionUnionType <|-- UnionTypeReflectionIntersectionType <|-- IntersectionTypeType <|-- BuiltinTypeType <|-- ObjectTypeType <|-- TemplateTypeType <|-- CollectionTypeType <|-- GenericTypeType <|-- UnionTypeType <|-- IntersectionTypeObjectType <|-- EnumTypeEnumType <|-- BackedEnumType

By doing that way,UnionType andIntersectionType inherit from theType class and, as well, from theReflectionUnionType and theReflectionIntersectionType. And of course, it's not possible in PHP to inherit from two classes at the same type.

Plus, theUnionType andIntersectionType will be considered as aReflectionNamedType which can be weird.

So I see two solutions here:

1. Do not inherit fromReflectionUnionType neitherReflectionIntersectionType, and make theType inherit from theReflectionType:

classDiagramReflectionType <|-- TypeType <|-- BuiltinTypeType <|-- ObjectTypeType <|-- TemplateTypeType <|-- CollectionTypeType <|-- GenericTypeType <|-- UnionTypeType <|-- IntersectionTypeObjectType <|-- EnumTypeEnumType <|-- BackedEnumType

But we won't be that precise, and we'll miss out if something is added intoReflectionNamedType,ReflectionUnionType, orReflectionIntersectionType.

2. Turn theType class into an interface and make types inherit explicitly from the properReflectionType (ReflectionNamedType,ReflectionUnionType, andReflectionIntersectionType)

classDiagramType <|-- BuiltinTypeReflectionNamedType <|-- BuiltinTypeType <|-- ObjectTypeReflectionNamedType <|-- ObjectTypeType <|-- TemplateTypeReflectionNamedType <|-- TemplateTypeType <|-- CollectionTypeReflectionNamedType <|-- CollectionTypeType <|-- GenericTypeReflectionNamedType <|-- GenericTypeType <|-- UnionTypeReflectionUnionType <|-- UnionTypeType <|-- IntersectionTypeReflectionIntersectionType <|-- IntersectionTypeObjectType <|-- EnumTypeEnumType <|-- BackedEnumType<<interface>> Type

But we have no way to enforce theType interface to be implemented by aReflectionType

WDYT?

About using Reflection and make the types classes extend it I'm kinda against it since it will only make the component harder to maintain with no real DX improvement. All the stuff we added are there to make types easier to manage and current Reflection isn't that easy to use.

@Korbeil Reflection is a low level API used only for advanced use cases. Type introspection as well. App developers (unlike framework and library authors) should not have to use them directly. The DX matters less than performance and maintainability for these use cases. And best perf and maintainability is always achieved by relying only on the standard library without needing extra code. Currently, the PHP stdlib doesn't expose all the features we need, but the history of PropertyInfo proved that features are being added, and it's an open goal for the PHP project to support generics and the like. In the future, this component will hopefully not be useful anymore and will be deprecated (same for PropertyInfo), which is good. IMHO TypeInfo and PropertyInfo should try to reduce the amount of work that maintainers will have to do to switch to the PHP stdlib when generics and similar features will be supported.

@dunglas I don't think there is much work needed out of resolvers (which was the same in PropertyInfo extractor) for the maintainers. And if PHP starts to have a better Reflection for types will be welcome but we don't have that yet. Also about performance, extending Reflection would mean having to call Reflection everytime we use a Type class, this is clearly not something that should be done, we want this component to be the most performant possible.

Hi! nice work there :)

2 questions:

• Do you think it could be useful to use generics on the classes defined here?
• is it scope to include even more stuff found in Psalm/PHPStan? such asint<0,max>,value-of<MyEnum>, etc. ?

Thank you@mtarld.