Decouple AnnotationDriver from doctrine/annotations

[derrabus]

AnnotationDriver is a helpful utility class for all drivers that read metadata from annotated class files. It's main advantage is the ability to search paths for suitable class files.

Unfortunately, it is currently coupled to the doctrine/annotations library. The ORM uses this class for its AttributeDriver which feels like a hack currently.

I'd like to decouple the class by removing the $reader property and making the isTransient() method abstract in 3.0. This PR prepares the necessary deprecation layer.

[stof]

could be avoided by adding treatPhpDocTypesAsCertain: false in the phpstan parameters, which makes phpstan accept cases where a type check is done in the code that validates a type defined only in phpdoc (because phpdoc types are not enforced) while type checks done on a value that passed through a native type are still reported.

[stof]

Maybe the right solution would be to extract most of the logic to a new parent class that does not use annotations in its name instead of deprecating passing an annotation reader to the annotation driver. Then, the ORM could extend this new class directly instead of extending AnnotationDriver for their AttributeDriver.

[derrabus]

Maybe the right solution would be to extract most of the logic to a new parent class that does not use annotations in its name

How would you name it? AbstractPhpClassFilesDriver?

[stof]

@derrabus I don't know. What is the feature actually implemented by that abstract class ?
But I'm quite sure that AnnotationDriver looks like the wrong name if the class does not implement support for annotations anymore.

[derrabus]

@derrabus I don't know. What is the feature actually implemented by that abstract class ?

If we remove the code that interfaces with doctrine/annotations, we recive an abstract driver that is able to discover class names from filesystem paths.

But I'm quite sure that AnnotationDriver looks like the wrong name if the class does not implement support for annotations anymore.

Yes, possibly.

[greg0ire]

 How would you name it? AbstractPhpClassFilesDriver?

If that driver is meant to handle metadata located next to the properties, class names etc. it defines metadata on, how about AbstractColocatedMetadataDriver? I'd avoid having Class in the name because of #224

[derrabus]

Closing in favor of #246