Alexander Raskin

Nice, though I see some potential problems here I'd recommend to fix before putting it into Apex

Unix issues:

1. mkdir 777

Code issues:

2. action = null, next line action = something

3. if and elseif that does the same should be replaced by OR

4. storing last action is useless, and php is stateless

Concurrency issues

4. fopen(.., 'c') doesnt truncate file, therefore new shorter cached content will replace old one only partially, forming an incorrect file content and invalid json

5.flock + fwrite in userland is way slower then just fileputcontents and same logic implemented in C land. May be critical and if someone decides to intentionally load a page using it multiple times in parallel.

6. fclose outside of try-finally may never happen, same about flock(lock_un). critical if you suddenly decide to use this in a command line app.

7. destroy traverses directory instead of directly accessing file. Very IO expensive and performance slow

General issues:

8. hardcoded config (cache dir)

9. no parameters validation. $expire can be not int and name can be "../../index.php".

10. error suppressing with @

Architecture issues:

11. Static is not testable as every test case will have side effects on other classes

12. It's not injectable as dependency, therefore other classes will result strongly coupled on it.

13. It is not replaceable. You cannot substitute file cache with apc cache when time comes.

Woot?

14. File as cache? You really don't have apc or memcache ?

15. There are more comments then code (and more issues then code as well)

16. One of the strongest parts of php is the wide range of libraries ready out there. Just use of of the existing caching implementations.

Other then that, not bad ;)