On Sat, Mar 9, 2019, at 8:11 AM, Gabriel O wrote:
> Thank you for your response!
>
> Not sure I understand the lazy connection example though. If item with
> connection is passed to another pool, laziness should still work, since
> item is managing its state and loading itself, isn't it? On the other
> hand, when passing non-lazy item without connection to pool that
> expects lazy items, shouldn't it work as well, since there is nothing
> to load anymore?
>
> And yes, it’s clear to me that contracts are not limited to just type
> hints, but such expectations needs to be documented in contract. Same
> would be in your iterable case. If it wasn’t documented what type of
> elements it should hold in contract, it’s expected it doesn’t matter.
Imagine 2 Pool implementations; one is backed by Redis, and greedily loads data
into the item object. The other is backed by MySQL and does so lazily by
passing the PDO object to the Item.
Consider trying to update an item like this:
$item = $redisPool->getItem('foo');
$item->set('new value');
$sqlPool->save($item);
SqlPool internally does something like $item->saveYourself(), assuming that the
Item has a PDO connection in it that it will use. A RedisItem, however,
expects that RedisPool will call get() and its own $item->getExpiresAt() to
extract information and write to Redis itself, using the RedisItem as just a
dumb data carrier.
The Item interface is just the calling library-facing portion. The Item and
Pool may have other methods they use to communicate that are not part of the
spec, and thus not standardized. Passing an Item to the wrong pool can then
end up calling a method that does not exist.
Hence the contract here is documented as "it only works with the pool it came
from", for exactly that reason.
--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/b57561ee-02fb-4f9d-8726-aa95ec9c8b9a%40www.fastmail.com.
For more options, visit https://groups.google.com/d/optout.
