Callback type detection

[Christoph Kappestein]

Hi, we have a case where we parse a type like \Acme\MyCollection<Callback> where Callback is an actual PHP class located under the Acme namespace, this works for every type except the Callback class, since it gets resolved to a Callable_. We have found that there is a keyword list which also includes callback as keyword and since all classes are lower cased this is probably the reason why it gets resolved to a Callable_ and not the actual class \Acme\Callback.

There are multiple solutions to this problem like:

• Removing the callback type since we have already callable
• Make the keyword detection case sensitive
• Add a removeKeyword method to the TypeResolver

Please let me know your thoughts, if needed I can also provide a PR for this.

[Jaap van Otterdijk]

Thanks for reaching out to us!

I think this is not an easy bug to fix, this library introduced a number of keywords that will always be reserved for certain cases.

As this library is just focusing on type resolving per file, which makes it lightning fast, we have some limitations, for example we are not able to detect the existence of classes in the same namespace. Php itself could do that, but as far as I know, classes are only loaded when they are used to create an object.

The callback keyword does exist for a while now, and we cannot remove it as this would impact other users, so that would be a backwards compatibility break. It's not worth it to do that for just one use case.

Making keywords case sensitive is also a breaking change, but even a bigger one than removing the keyword. This would have to many impact and would make the library unusable for some coding standards. This is a no go for me.

Your final solution to be able to remove keywords could be an option... But it will possibly cause side effects or give more issues as we cannot assume that all consumers are using the same instance of the type resolver. For example when using symfony you could run into issues when the framework creates an instance. Which it will do when using the serializer.

Given the amount of downloads of this project we have to be careful with changes. Unless this was a unintended bc break, which I think it wasn't, I would not be open for any changes regarding this particular issue.

I would recommend to alter the class name in your project as that will not impact others, or import in in this file with an alias.

I don't see why we have to change our code as the keyword was reserved for more than 10 years without any issues, and give the possible impact of such a change on the php-ecosystem.

I'm sorry to make this statement. But I hope you understand our position.

[Christoph Kappestein]

@jaapio thanks for your feedback and explanation and no problem I can understand your case. If I use the FQCN it also works as expected, so it is only an edge case for this particular class name.