no strong opinion about this. I created a LockFactoryInyerface in the original PR (#21093) But removed afterwards (I don't remember who suggested it. Probably @nicolas-grekas if I remember well...)

The factory is pretty simple and I never needed another implementation or decoration. Do you have a use-case in mind?

The rate limiter provides bundle config like:

framework:
  rate_limiter:
    acme:
      lock_factory: # Any service that is an instance of LockFactory

It does not make much sense to have a config value where you pretty much have only one valid config.

Same thing with the constructor of RateLimiterFactory. The third argument should be null or an object of the LockFactory class. The dependency inversion principle says that it should be an interface instead.

So no, apart from these more or less academical reasons, I dont have a use-case.

It does not make much sense to have a config value where you pretty much have only one valid config.

hmm, the factory take a store in argument. You may have instance of the Factory in the DIC.

framework:
    lock:
        foo: redis://localhost
        bar: flock

provides 2 factories

Yes, sure, you may have multiple lock factories which all would be different objects of LockFactory. But that is still missing my point of dependency inversion.

The PR is updated. There is a lot of deprecated service names and aliases.

I've never felt I needed a different implementation of the lock factory. The factory is just a tiny bit of glue code around the store. I don't oppose this change, but I think the current way of not having an interface is just fine.

I agree that this change is mostly academical.

By the way, I think we can remove the "BC Break" label. You've changed the constructor signature in a compatible way and the lock factory is assigned to a private variable and is never exposed.

I think it was me not wanting this interface and I haven't changed my mind. "academic" reasons are probably the worst :)

"academic" reasons are probably the worst :)

Hm... I disagree with that.

Thank you for reviewing and for the feedback.