In yesterday's post, someone wondered why I keep picking on PHP's Variable Variables. Well, to be brief, it's a maintenance nightmare and is akin to taking a shortcut through the minefield: you're pretty certain where all the mines are, but anyone following your path can get into a lot of trouble. I wonder if the defenders of this are the descendants of folks who complained about removing COBOL's ALTER verb. But I digress, here's yet another reason why empowering developers with things like variable variables is as safe as letting kids play with scalpels:

$sql = "select admin_function 
from zone z, zone_type zt
where z.zone_type_id = zt.zone_type_id
and z.template_id = $template_id
and position=$position and parent_id=$page_id"
; $admin = runsql($sql,true); if ($admin) {return $admin($page_id, $position, $target);}

James explains:

This code is actually out of the same site (in production) that I posted the rot13 function. runsql is some bizarre attempt at abstraction.  If the second argument is true, then it will select the first row and column and return that string.   So, the function name is pulled from the database and stuffed into a variable, which is then called as a function.  Of course you can't grep [search text within files] for the function call because it is in a variable. 

Phew. Okay, that's enough PHP for a while now :-D. Don't worry, if you're really itching for more, Benson Wong recently launched a site just for such oddities: If its been at least twenty minutes since you've eaten, then go check it out!

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!