Drop CachedReader

[Majkl578]

See #204 (comment) for reasoning.

Closes #204.

[alcaeus]

FWIW, I agree with dropping CachedReader in its current form, but think we should still provide a CachedReader.

For one, caching is not "marginally" useful. While it makes sense that resulting structures (e.g. ORM/ODM metadata) should be cached, this assumes that only a single consumer will ever read annotations for a class when in fact multiple packages may want to read their annotations from the same class.

To bring a concrete examples, here are the different types of annotations found in a single class:

• ODM metadata
• JMS serialiser metadata
• Algolia search indexing definitions
• Validation constraints

I believe providing a small class that allows caching read annotations for classes in a PSR-6 or PSR-16 cache is something we should definitely do. Providing such a class also doesn't cause a huge dependency tree overhead as we'd only have to require the PSR interfaces without pulling in or even suggesting a concrete cache implementation. Providing a CachedReader implementation also avoids multiple frameworks having to re-implement this which they'd most likely do if we didn't ship such a reader.

I'll leave it up to @Majkl578 to decide whether to merge this and re-introduce a new CachedReader or whether to close this PR in favour of changing the existing implementation.

[lcobucci]

I think that this is a great thing. Most libraries that rely on annotations have their own cache structure.
Having a caching layer for "temporary information" (as in: only used to create configuration objects) doesn't add much IMHO.

[Majkl578]

@alcaeus While I had the same opinion as you, it's true that annotations are a format to describe stuff, pretty much like XML or JSON or YAML. So in the end the annotations reader is an intermediary tool which should only provide transient data that are transformed into library/application-specific metadata.
Also from what I've seen often the CachedReader is used together with ArrayCache which hardly brings any benefit anyway.

So IMO removing it is a good call, and in case anyone provides a valid use case we can add new caching decorator on top of PSR-6/16, ideally as a separate package (annotations-cache).

[alcaeus]

@Majkl578 very well then 👍

[Ocramius]

LGTM 👍

Question on when to turn master into 2.0.0 remains (should I release 1.7.0 and call it a day for 1.x?)

[Ocramius]

As per discussion with @alcaeus and @Majkl578, master is already 2.0.0, so this is going there.

[Ocramius]

@Majkl578 this requires a rebase, since the performance tests still have the CachedReader in there

[Majkl578]

Rebase done.