Improved Phalcon\Cache\Backend\Apc

[sergeyklay]

Hello!

• Type: new feature
• Link to issue: Remove deprecated code #12098, APCu classes #11934

In raising this pull request, I confirm the following:

• I have read and understood the Contributing Guidelines?
• I have checked that another pull request for this purpose does not exist.
• I wrote some tests for this PR.

Small description of change:

• Improved Phalcon\Cache\Backend\Apc by introducing support of APCu
• Improved Phalcon\Annotations\Adapter\Apc by introducing support of APCu

Thanks

[Jurigag]

I don't like this. Why just not introduce new apcu classes and later remove apc in phalcon 4?

[sergeyklay]

Why don't like?

[Jurigag]

Cuz as i wrote - i would like much more just seperated classes. I don't like one class to be adapter for both apc and apcu.

[sergeyklay]

Yes, I'm understand. But could you please elaborate on that. In order to discuss something, we need a reason. "I don't like" not reason.

[Jurigag]

Well we will remove necessary to have checks, conditions etc, also code will be much cleaner. As i saw in other frameworks if they had support for both apc and apcu - it was done in seperated classes.

[andresgutierrez]

We can have this for BC reasons and fully deprecate apc in Phalcon 4, what do you think?

[Jurigag]

Not deprecate - just remove apc more likely, but then we would need imho change apc classes names to apcu cuz it will no longer work with apc obviously. That's why seperated classes seems more suitable - someone could just switch to apcu in 3.1 and he would need to do less stuff in phalcon 4.

[Jurigag]

Also notice that atm if someone is already using php7 + apcu + phallcon he needed to install apcu_bc. So this classes work for him anyway and he will not notice any difference, except those additional checks.

And if someone would like to use apcu + php7 + phalcon then he would need to change to new class in phalcon 4, cuz there is no point having it named as Apc when it will be working only with Apcu, just that's why i would like to introduce seperated classes, cuz there will be really no difference from developer point of view, but he will have less to do when switching to new version.

[Jurigag]

Php5 apcu already have apc emulation builtin so apc_fetch function will just call apcu function for php 5 users this change will be totally useless

[Jurigag]

How this combined have advantage of being compatible in the next years like if someone who already wants to use apcu is already using old class and in phalcon 4 he would need needs to change name anyway? Just separated classes are way to go, new developers could use then new classes and have less things to care about when switch to phalcon 4, old would need to change anyway.

[Jurigag]

I think yes - it needs to change, cuz it no longer will work in phalcon 4 with APC, just only with APCU, so why keep old APC name? NO, apcu always uses apcu_ functions internally in php 5, even when you will use apc_ functions.

https://github.com/krakjoe/apcu/blob/PHP5/php_apc.c#L1534

Just order of extension will matter i think, if you have loaded apcu after apc in php5 then apcu will be always used i think. Anyway - you should use only one.

[Jurigag]

I just don't see really why we can't have both adapters. In all known major frameworks they have apcu classes.

[niden]

I think we should have 2 adapters.

We can deprecate Apc at a later stage without having to touch the adapter to remove the apc related code from a common adapter.

My 2 cents

[sergeyklay]

#12788, #12786