It may/will be painful, yes.
I have some ideas to mitigate but haven't tested them yet.
The current pain points are:
One mitigation I'm thinking of is having some sort of generic wrapper class which takes the real Symfony cache object as an argument, and we can have slightly more familiar
This doesn't solve all of the above but the API changing is probably the most significant (in that it's not quite a simple find and replace).
I have some ideas to mitigate but haven't tested them yet.
The current pain points are:
CssRenderer::__construct
signature has changed and this method is extendable with the XFCP- Cache adapter objects are obviously different types now so third party code which expects particular types for arguments or returns will break and will need updating
- The API is slightly different, as you note, with
\XF::cache()->fetch($key)
(more or less) becoming\XF::cache()->getItem($key)
and\XF::cache()->save($key)
now requiring a cache item to be passed in rather than a string cache key.
One mitigation I'm thinking of is having some sort of generic wrapper class which takes the real Symfony cache object as an argument, and we can have slightly more familiar
fetch
and save
helper methods attached which proxy through to the adapter class.This doesn't solve all of the above but the API changing is probably the most significant (in that it's not quite a simple find and replace).