Right then. Headaches are contained for the time being, so...
* I have rearranged the code considerably. Specifically, the interfaces
now live, for now, ONLY in:
https://github.com/Crell/Cache
The utility classes now live ONLY in:
https://github.com/Crell/Cache-Util
(Both of those will move to the FIG organization once the spec is approved.)
The PR itself now contains ONLY the non-interface parts:
https://github.com/php-fig/fig-standards/pull/149
Maintaining the interfaces in 2 places was just too much of a hassle, so
I've split the spec for now. I will merge the repo code back into the
spec proper when it's ready to send to Paddy for final review; not
before. Hopefully this will also keep people from commenting on the PR
instead of here. :-) (I know, hope springs eternal.)
* I've renamed the interfaces as discussed previously. However, if
"pool" is so confusing that we have to go with "cache-item-pool", that
to me says pool is the wrong noun to begin with. In Drupal we've used
"bin" for years without issue. I recommend we switch to that name as
CacheBin is quite self-explanatory. Thoughts?
* The Collection support that was included previously was based on prior
discussions on the list from last fall. Apparently there's enough
people that dislike that approach that I've pulled it back out. Please
suggest an alternative. :-)
* There have been a few other tweaks based on feedback here and on the
PR. See the commit log for details. Of particular note, I kept the
split of set() and save() that was introduced with the collection
support. For one, that part did seem to be fairly popular. For
another, I do want to get multi-support in (as do most people per
previous poll), and having that split is mandatory for that to work. No
sense pulling it out just to put it back in again.
* While doing the memory implementations for the collection support, I
began to question the use of save() on the item. For multi-set to work,
we by definition have to dissect the item object and run the save
routine *in the pool*. Just iterating over the items and calling save()
doesn't buy us any performance benefit on multi-set-capable backends.
So if the pool is going to have to be able to dissect an item and save
it itself, then saving a single item is... exactly the same. ("One is a
special case of many.") That makes Item::save() redundant. I will write
more on this later, but for now, any new proposal for multi-handling
should include at least a memory implementation to see if it actually
makes sense in practice.
--Larry Garfield