This would only work if the used terms have an equal purpose and meaning, Resettable has a different purpose in Cache than OutputFormatterStyleStack or Compiler in the Expression-Language.

Basically this would make the interfaces extreme generic in purpose and less about their specific situation. A Trait can be easily re-used as it's simple code-level copy-paste but doesn't enforce an interface contract.

This would only work if the used terms have an equal purpose and meaning

Correct, and that's actually the exact purpose of the proposed interface. I don't know why you state that they have a different purpose in your list, because AFAIK, they have the exact same one: resetting an object to its initial state. This is even more apparent when considering that all (most) these existing "reset" methods are bound to "kernel.reset" tags.

Maybe we should use the discussion of PR to assemble a list of classes, interfaces and traits that could possibly be moved into the abstractions package, to get an idea of where we would be heading to with this idea.

@derrabus why not. Here is my short list (I would really try hard tonot add any classes here, even abstract ones):

• CacheInterface, as derivated from[Cache] Add [Taggable]CacheInterface, the easiest way to use a cache #26929, which will require also aCacheItemInterface
• ServiceSubscriberInterface from DI component,ServiceProviderInterface from[DI] ServiceProviderInterface, implementation for ServiceLocator #25707 and aServiceLocatorTrait derivated from ourServiceLocator class

There might be more abstractions that we could extract from other components (Console, EventDispatcher, Lock, Messenger, Routing, Translation, HttpKernel, etc.?)

I really like the idea of separating abstractions from implementations.

I would really try hard tonot add any classes here

Regarding EventDispatcher, a (dead-simple) class would be among the candidates for me:

• EventDispatcherInterface
• EventSubscriberInterface
• Event

Event could be split into an interface + a trait, but I don't see much benefit here.

Moving those to interfaces into an abstraction package would allow components to define optional event subscribers without depending on the actual event dispatcher. We could also simplifycode like this.

This PR is weird, seeing#6129 was voted down on. What has changed?

Thanks for the link@ostrolucky. About your question, re-reading my own downvote, I then stated:

Symfony didn't embrace the mission of providing generic interfaces on their own

that's exactly what I'm proposing here: have the Symfony project broaden its missions a bit, and allow itself to publish interfaces on their own for genericity. The benefits are well discussed and presented in the issue. Why did I change my mind? Because I feel like not having this package is preventing us from some kind of innovation we'd like to do. E.g. taggable cache items, this linked cache interface, the attached reset method, etc. It comes also as a realization that the FIG is not the right place for all of these: I don't expect everyone in the FIG to agree on all things we'd still like to do. And this is fine, we don't have the exact same goals obviously. We need our own freedom on the "abstractions" topic, so that we're able to contribute to this space also. Some topicscould be of interest to the FIG (e.g. taggable cache items), still that shouldn't prevent us from being able to move forward at our own pace.

I like the idea of creating standards by extracting or defining interfaces out of established and working solutions. This is what PSRs are missing in many cases.

However, how do you see thesymfony/abstractions package to be consumed by others?

My main issue with this idea is that the package wouldn't be cohesive, as a lot of unrelated interfaces would be packaged together. If I only need theResettableInterface I shouldn't be forced to bring in theServiceSubscriberInterface.

@nicolas-grekas to better understand the purpose (and limits) of this new package, which of the following packages fits the idea of symfony/abstractions better?

• Laravel Contracts (https://github.com/illuminate/contracts): it only contains the interfaces of the framework. No traits or shared code.
• Doctrine Common (https://github.com/doctrine/common): it's the usual "common" package found in lots of software projects and contains both interfaces/contracts and commonly shared code.

Thanks!

a lot of unrelated interfaces would be packaged together

That's a desired property of the package IMHO: it will ease discoverability and dependency maintenance (there are some comments in#6129 on the topic). We might reconsider later if the number of interfaces grows out of control, but I don't expect this to happen anytime soon. Meanwhile, we could/should group domains in subnamespaces, when cohesiveness is desired (not the case for ResettableInterface, but could be for the mentioned Cache interfaces.) The fact that you get potentially unused interfaces poses no issues IMHO.

@javiereguiluz certainly not like doctrine/common, which is not an abstraction at all. What I presented above: this would contain interfaces (=abstractions), related documentation defining their semantics (in docblocks), generic traits (=type-less behaviors) and reference test suites when applicable (of primary importance, see eghttps://github.com/php-cache/integration-tests/ for what I mean).

ping @symfony/deciders

This seems like a simple optimization: by moving some interfaces to this component, the only practical difference is that you're allowing a library that wants to use that interface (butnot use our implementation) to depend on the smallerabstractions component instead of needed to require the entire component (but then only use the interface). A real-world example would ishttp-kernel, which is used in several libraries that don't use its implementation (e.g. Laravel who only referencesHttpKernelInterface &HttpExceptionInterface).

Are there any big downsides?

Thecontracts should have a different versioning than Symfony. As we won't break BC for instance, we just have to increase the minor version. Having a 5.0 version next years does not really make sense. So, here is the plan: we keep the code undersymfony/symfony to make it easier to move interfaces from the actual code to the contracts ones, but the release cycle is going to be different and done directly via the subtree-split.

Here we are, the interface is nowResetInterface. PR green.

we keep the code under symfony/symfony to make it easier to move interfaces from the actual code to the contracts ones, but the release cycle is going to be different and done directly via the subtree-split.

Makes perfect sense to me, everything ready to put it into practice :)
I've updated the branch-alias and the composer.json to reference v1.0.

Thecontracts should have a different versioning than Symfony.

I absolutely agree.

the release cycle is going to be different and done directly via the subtree-split

I see how keeping the contracts inside the monorepo would ease the extraction of more interfaces, but I must admit that the detached versioning confuses me already, thinking about branching tagging of releases. A separate repository would be easier to maintain and understand in the long run, I guess.

How about this: We could start with the contracts in the monorepo to ease the extraction for now and right before the feature freeze of Symfony 4.2 (which would be 1.0 of the contracts), the subtree split becomes an independant repository like the polyfills or the monolog bundle.

@derrabus we'll have some time to figure out what works best. For now, we anticipate that the easiest to maintain could be a subtree-splitted repository.

Status: needs review

Thank you@nicolas-grekas.

\o/ thank you all for the discussion, to the core team for their support and to fabpot for merging.
There are more interfaces to move in contracts before releasing 1.0 in November.
PRs welcome!

There are more interfaces to move in contracts before releasing 1.0 in November.
PRs welcome!

I'd love to help. I would start with the event interfaces as I suggested in my comment:#27093 (comment)

Do you track somewhere what needs to be done and who's already working on which part?

I just createdhttps://github.com/symfony/symfony/projects/7 so we can track ideas and progress.
Please open issues/PRs and add them to the project (if permissions don't allow it, @symfony/deciders can do it.)