Build an AST (Abstract syntax tree), before resolving classes and constants?

[donquixote]

Hello there, every time I looked at the Doctrine annotation discovery (today, and many years ago), it made me wonder: How would I implement an annotation parser?

Currently, \Doctrine\Common\Annotations\DocParser does two things at once:

• Parse annotations in the doc comment.
• Resolve class aliases and constants.

This makes the component more complex than it needs to be.

Instead, this could be split up:

• One component to parse the doc comment as an abstract syntax tree.
• A separate component to resolve class aliases and constants.

For absolutely no reason, I am posting a link to my own annotation parser, which follows this philosophy (but does not care about annotation classes). https://github.com/donquixote/annotation-parser

This entire issue is "food for thought". I currently do not have a personal use case where I would absolutely need this change.

[Ocramius]

@donquixote seen https://github.com/doctrine/annotations/pull/75?

[donquixote]

@Ocramius The discussion in #75 PR is so long :(

I don't understand why #75 wants to change everything at once. Imo one can and should first refactor or rewrite the annotation parsing without any BC break in userland.

Or to be more accurate: Libraries with annotated classes should not have to change anything. Libraries which actually call the annotation parser to look for annotations would need to change.

I think the annotations here are meant for libraries that define their own annotation classes, right? So changing this namespace would not affect the average annotated class.

[donquixote]

@Ocramius I started an 1.0 branch of https://github.com/donquixote/annotation-parser The 0.0 branch had some confusing aspects, which I wanted to get rid of.

I think some of this can be useful for doctrine/annotation 2.x.

There are still some aspects that I am not fully happy with. But I think some parts of the architecture are better than currently proposed in the PR.

It uses a custom parser. But I think one could easily swap it for a hoa parser.

The interesting part is ObjectResolverInterface. This interface is free of all the assumptions about annotation classes, imports and namespaces, and about the parser or AST.

[Majkl578]

@donquixote If you're still interested in seeing AST in Annotations 2.0 and/or would like to discuss things, you can join us on Symfony Slack (get invitation here) - channel #doctrine-annotations2. We already have a grammar, AST and metadata concept, every input will be welcomed. :)

[TomasVotruba]

Hi everyone,

I've just noticed this issue. We needed something similar - to separate parsing and evaluating (e.g. of constants) in Rector - e.g. to rename any class name on any level without getting crazy.

It run on symplify/simple-phpdoc-parser (https://github.com/symplify/simple-php-doc-parser), that is using phpstan/phpdoc-parser (https://github.com/phpstan/phpdoc-parser).

The Doctrine annotation part is added here:

https://github.com/rectorphp/rector-src/blob/c7b96e07d99a0eeb8bb67b9ae90e58130043aa65/packages/BetterPhpDocParser/PhpDocParser/DoctrineAnnotationDecorator.php#L63-L112

It looks serious, but it's just dummy node traverser that translates doctrine-like simple tags to propper AST node :)

---

There is a post that describes features and how it works together - From Doctrine Annotations Parser to Static Reflection