Should there be one or several interfaces for ReponseTagger?

[André R.]

Working on type hinting against TagHandler on our abstraction for FOSHttpCache, however for other parts of our stack would in the future rather want to type hint against interfaces in FOSHttpCache itself.

So would there be an idea to add some interfaces which probably won't change in a possible 3.x or 4.x version?

So what I need is something like this for usage to tag response:

interface ResponseTaggerInterface
{
    public function addTags(array $tags);
}

Naming might be wrong, ResponseTagger class is covering several use cases, another clear one is ResponseTagWriterInterface or similar as called by kernel response event listener in bundle, this also might deserve an interface.

[David Buchmann]

the idea to not have interfaces is inspired by the symfony philosophy of not having an interface for things that are just one implementation. we could have a ResponseTagRecorder interface - but are there use cases to have a different way to tag responses than with the current ResponseTagger class?

[André R.]

interfaces is inspired by the symfony philosophy of not having an interface for things that are just one implementation

That might be, but afaik we always type hint against interfaces when dealing with symfony. But I'm maybe over thinking the fact that ResponseTagger handles several concerns.

Context:
I'm trying to simplify how our users are asked to tag responses on custom logic (we take care about it for native CMS content views and custom content view controllers, but for completely bare bones symfony controllers users will need to do this themselves using docs)

To be honest, what I would really like to document in regards to this is something like: $response->addTags($tags);... That would be 🎯 on DX for adding tags, but I guess we then need to start thinking about the good old discussion of moving some of the logic to Symfony.

[David Buchmann]

$response->addTags($tags);

indeed, that would be very elegant. although, there are situations where you can't because the response does not exist yet, e.g. in twig templates. i think that is why we introduced the tagger originally.

OptionsResolver for example has no interfaces. but if you think it would be very helpful, i would be ok with adding a ResponseTagRecorder interface (we chose to not use the Interface suffix in this library - its an antipattern in OO thinking). if you want to do it, what would be the right name? TagRecorder or ResponseTagRecorder? i think response needs to be in the name, there is also the CacheManager recording tags that need to be invalidated, but invalidation happens at flush time only, so in i way it "records" too.

[David Buchmann]

i guess for the methods to apply the tags, we don't need interfaces - there its framework wiring and no need for abstraction imho.

[André R.]

ok, I get your point. So will close this for now and give it some more thought as I try out different things.

[David Buchmann]

okay. as said, if you think a ResponseTagRecorder (or better name for that thing) would be fine with me, to avoid coupling random places to a specific implementation. in a way, we already have a weird architecture now with the response tagger of the bundle both supporting psr and symfony responses, instead of having some shared code but separate taggers and setting up the correct tagger for one's framework.