Investigate possibilities to parse attributes without reflection

We had a discussion about DrupalCon Lille about this.

One idea was to create an 'attribute registry' - i.e. to essentially parse out all attributes from a file at once and store them somewhere in a format.

That way if a single file contains (or might contain) multiple attributes types that all need to be discovered, we would only check that file once instead of once-per attribute type.

However it would be complex to implement so we thought better to see how we're doing after conversions.

Ideas like checking for #( worth doing first too if they're effective.

Have you looked at https://github.com/olvlvl/composer-attribute-collector?

Move nikic/php-parser up from dev dependency to normal and run something like https://gist.github.com/chx/9f289ffd541701228ba98243dd7eaff7

@mstrelan it uses reflection https://github.com/olvlvl/composer-attribute-collector/blob/a3d45a2e9bab... it just does it when the file gets installed by composer, it would be a very different development workflow compared to what we have now.

This might be less necessary with 📌 Add a filecache-backed attribute parser Active which will persist attribute parsing between full cache clears (but not yet between deployments, but see related issues).

One thing to consider besides performance issues, a problem that's come up in 📌 Convert MigrateSource plugin discovery to attributes Active and 🐛 Changing plugins from annotations to attributes in contrib leads to error if plugin extends from a missing dependency Needs review is that attributes can't be read via Reflection on classes that implement missing interfaces, extend missing classes, or use missing traits, in the case that the missing dependency comes from an uninstalled module. While Reflection will throw an exception for a missing interface or class, PHP will fatal on a missing trait. The exception thrown during plugin discovery was handled in 🐛 Changing plugins from annotations to attributes in contrib leads to error if plugin extends from a missing dependency Needs review , but a solution for handling missing traits gracefully is still outstanding.

Using something like nikic/php-parser to retrieve attribute values without might be a viable way forward to retrieve at least some attribute values in the case of missing dependencies.

#12 is interesting. And a possible counterpoint to #11 is that the caching rather than cancelling this issue out, gives us more options to potentially adopt a slower but more memory-efficient attribute parser.

Created 📌 Use alternate parsing method for attribute-based plugin discovery to avoid errors Active to explore using nikic/php-parser to help with plugin discovery per #12 📌 Investigate possibilities to parse attributes without reflection Active and put up an MR.
Hat tip to @ghost of drupal past for the library suggestion and gist.

Surfacing a comment I made in 📌 Use alternate parsing method for attribute-based plugin discovery to avoid errors Active about missing dependencies that I think warrants mention here outside the specific context of plugin discovery:

That being said, I think the scope of the missing dependencies issue will expand as attribute-based discovery expands to routes ( 📌 Use PHP attributes for route discovery Needs review ), and services ( ✨ Directory based automatic service creation Needs review , 📌 Support #[AsEventListener] attribute on classes and methods Active , ✨ Support hooks (Hook attribute) in components Active ), etc. It might actually make sense to provide some sort of missing-dependency-safe wrapper for Reflection to address all these use cases.