@danut007ro seems simple/solid to me.
@guilhermeblanco is there any location in the ORM where we can use this?

@Ocramius Maybe the redis providers could use multi or pipeline?

@Ocramius the SLC should be review to see whether it can benefit from it (this is the place benefiting from MultiGet already)

I don't think it's a good idea to introduce a new interface for this. IMO MultiGetCache should be merged into Cache in 2.0 anyway. CacheProvider already emulates fetchMultiple anyway which is always possible. And the same would be true for saveMultiple.
So IMO this features should be implemented without an interface. Otherwise we would just create an interface that we don't want in the long run at all.

@Tobion a few things:

• changing an existing interface needs a strong reason to do so
• save and load can already be on separate interfaces: they are not necessarily symmetrical operations anyway
• this patch is in line with already quite successful interface segregation of this component: I'd rather keep it like that, then aggregate all interfaces into something like CacheProvider for 3.x

From my point of view, the patch is ok, but indeed we may re-design some of the interfaces for 3.x

Well if ISP is really wanted for such a small domain, then it should be done fully. Currently it's just random and more based on historic reasons than on ISP. For example, why the getStats in Cache when it is probably the least common used method. And if multi save and multi get are different interfaces than, single save and single get should be too. Otherwise it's arbitrary.

@Tobion fully agree. I think Zend\Cache does it quite right on that front (each adapter has a series of capabilities)

@Ocramius I updated the code according to your review (thank you for it). Have a look and tell me what you think. Thanks!

Looks good to me.

Waiting for @guilhermeblanco to do a last sweep.

Nice, this will become useful.

got a 👍 from @guilhermeblanco! Merging \o/

Thanks @danut007ro