On Fri, Mar 8, 2019, at 4:28 AM, Gabriel O wrote: > Hello all, > > I would like to ask for help to understand why was line > > > Calling Libraries SHOULD NOT assume that an Item created by one > > Implementing Library is compatible with a Pool from another Implementing > > Library. > > introduced in commit 9cfeacf3b9913793aa2a159ffe1d04080349b281 > > This example is now used as justification for rejecting non-specific > classes that interface says implementation supports. > > This is visible in Symfony PSR-6 implementation > https://github.com/symfony/symfony/blob/b0a85ad015ced23f66ebd6215176e2cf5161e9ca/src/Symfony/Component/Cache/Adapter/AbstractAdapter.php#L199 > and Symfony HTTP client that is being designed now > https://github.com/symfony/symfony/pull/30414#pullrequestreview-211896443 > > I'm afraid LSP breakages will become now more common.
Hi Gabriel. The reason for that admonition is that for flexibility for the library implementer. Specifically, some implementations of a cache object may (and I believe do) pass a backend connection to the cache Item. For instance, a Redis connection or a PDO instance. That allows the Item object to lazy load a value rather than being just a dumb value object. If it were a dumb value object then yes, it would most certainly make sense to keep it portable. However, it was designed such that logic could live in either the Pool or the Item depending on the implementation but still expose the same API to calling libraries; cache Items should only ever be retrieved from the Pool and then put back into it, most likely within the same function. They're not something you would be passing around to different functions. As Nicolas notes in the thread you linked above, there's more to defined behavior and a contract than can be captured in a type hint. To use a trivial example, you can type hint something as an "iterable" but it has to be an iterable of something specific; passing an iterable of ints to a function that expects an iterable of PSR-7 Request objects is not going to end well, even if strictly speaking the type declaration would allow it. LSP is an important guideline, but there is also more to interface and behavior specification than just type compatibility. --Larry Garfield -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/3c18ffb6-625e-488b-8b0c-079cd16f12f5%40www.fastmail.com. For more options, visit https://groups.google.com/d/optout.
