instead of passing the cache here I would prefer using composition instead which decorate the default PropertyInfoExtractor something likehttps://gist.github.com/aitboudad/12419c2db6d19320c5fa

same thing for#16838

👍

I was thinking the same thing initially, but finally I'm not sure that it's a good idea:

• Performance (and cache) is not an "optional" feature. It should be enable for all implementations in prod and IMO it's why it belongs to this class.
• In the context of the Standard Edition it adds a lot of complexity and an overhead: it requires to use the service decorator feature to switch the class depending of the environment (the cache must be enabled in prod, but not in dev)
• In the context of the component, it makes it harder to enable the cache (one more class to instantiate)
• all other components using cache doesn't use composition for that (it is considered as a builtin feature)

When the PSR-6 will be ready, the argument can even be made mandatory (it's better to always use a cache) and aNullCache or something like that can be added for the dev environment (like with the Logger).

What do you think @symfony/deciders?

👍 Composition is much cleaner and should be used unless it is not possible, like with the property accessor cache.

double dots

just wondering: $arguments contains $context. But what does $context contain? Is it a big or small array of scalars? Something potentially non-serializable there?

For now it is only used in Symfony by the serializer extractor (a small array of strings). But it's a good concern because the context can be used by any custom extractor and can contain anything.

Do you know a way to easily retrieve an unique identifier from an array or should we try something like recursively replacing instances of objects by the return ofspl_object_hash()?

Maybe can we add a note in the doc of$context in interfaces that it should only contain scalar and serializable objects or it will create unexpected side effects?

It will avoid to add a costly (in term of performance) custom serialization process here.

This is not really meaningful.

"psr/cache-implementation": "For using the metadata cache.",?

setUp is a protected method

Quick search revealed there's few more occurrences. I'll send a PR to fix them.