4

I notice that a couple of weeks ago PHP 5.3 reached release candidate stage (woo!), but then seeing the list of already-deprecated functions finally being removed, that got me thinking about whether it would break any of my old code.

Short of doing a suck-it-and-see test (installing on a test server and trying it out), are there any sort of migration tools which can analyse your code to highlight issues? For example, if some scripts use the ereg_* functions.

SilentGhost
  • 307,395
  • 66
  • 306
  • 293
nickf
  • 537,072
  • 198
  • 649
  • 721
  • What version are you currently running? – cletus Apr 08 '09 at 22:54
  • 5.2.4, though that shouldn't matter? – nickf Apr 08 '09 at 23:00
  • Well I can think of issues if you go from 5.1 -> 5.3 that won't be there if you go from 5.2 -> 5.3. Of coruse current and new versions are both relevant. – cletus Apr 08 '09 at 23:03
  • In the article here: http://cvs.php.net/viewvc.cgi/php-src/UPGRADING?view=markup&pathrev=PHP_5_3 I don't see mention of removed functions. Can you link to where you saw that? – Benson Apr 08 '09 at 23:15
  • I know of a few things that get deprecated in 5.3 but not removed until 6. – cletus Apr 08 '09 at 23:17
  • well, even still... such a tool (should it exist) would be able to give warnings about deprecated functions too, I'd suppose. – nickf Apr 08 '09 at 23:30
  • I think that you should be able to turn on warnings somewhere and get info about deprecated functions. I can look it up if you'd like. – Benson Apr 09 '09 at 20:57

2 Answers2

4

One technique you could use is to take the list of deprecated functions that is being removed and grep for them. A little shell scripting fu goes a long way for things like this.

Let's suppose you have a file deprecated.txt with deprecated function names one per line:

for func in `cat deprecated.txt`
do
  grep -R $func /path/to/src
done

That will tell you all the instances of the deprecated functions you're using.

Benson
  • 22,457
  • 2
  • 40
  • 49
  • 1
    Rather than re-grep in a loop, it's probably more efficient to create a statement like: egrep -R '(dep_func_1|dep_func_2|etc...)' /path/to/src Another option would be to generate an xdebug trace file, which will include the names of called functions -- but it'd be hard to get 100% code coverage – Frank Farmer Apr 09 '09 at 00:33
  • Of course that would be more efficient, but it's a bit harder to write an easy-to-read shell script that reads dep_func_1, dep_func_2, etc. from a file and does the grep. I did it for ease of readability, not for speed. :-P – Benson Apr 09 '09 at 20:56
1

Nothing beats installing on a test server and running your unit tests. You do have unit tests, right? ;)

DGM
  • 26,629
  • 7
  • 58
  • 79
  • Unit tests are FTW, but I think he explicitly said he wants a heuristic that doesn't involve a test server. :-) – Benson Apr 08 '09 at 23:08
  • yeah sorry for the arbitrary caveat, but i was wondering if there was anything else besides that. Also, there's some third-party software for which I don't have any unit tests. – nickf Apr 08 '09 at 23:10