That was my first thought too, since the Reflection API lets you get to the actual parameter names... However, I'm not sure off the top of my head how pretty URL's would be implemented(probably would have to use mod_rewrite). There's also the URL prefixes he's implementing. I think he's giving up the efficiency of mapping _REQUEST params straight to arguments in favor of more features/flexibility. My takes on frameworks went the former route (straight mapping + mod_rewrite), but I've since become less hardcore about being minimalistic with URL's.
There is some additional overhead in mapping the the $_REQUEST params but it's not actually so bad.
Design decisions have been made to err in the favor of making user code simple and more expressive. Having some routing logic contained in the code and 'pretty urls' in mod_rewrite is much more difficult to approach.
I'm not sure what you mean by additional overhead... You're already using the Reflection API to to get to the names of the method arguments so that your /hello/$first/$last works, no? Or are you just relying on the order and assuming the developer puts things in teh right order, ie /hello/$foo/$bar works just as well?
If the former is true (you're already getting the param names), then there's no further overhead to map directly to $_REQUEST. I forget the exact Reflection syntax, but wouldn't it just be something like
$argsToPass = array();
$args = ReflectionMethod->getParams(); //you got an array of param names in the order they appear in the function
foreach ($args as $arg) {
if (!isset($_REQUEST[$arg])) { //check if the arg is optional and fail if not }
$argsToPass[] = $_REQUEST[$arg];
}
$ReflectionMethod->invoke($argsToPass);
I haven't touched this stuff in a while, so I might be completely off, but I'm not sure what overhead you're referring to...
Once again, I'm not defending this approach, as the extra logic you've put in to interpret the path probably makes things a lot more flexible and easier to debug.
Thanks for clarifying and the code bit. This is very close to what's actually going on. The 'overhead' I mentioned is minimal, and exactly what you described.
The names are important in mapping so...
/ !Route GET, $last/$first */
function foo($first, $last) {...}
Maps $first to $first properly, etc.
Indeed the hope is that this will be easier to understand and use.
Yes - first class attribute support would be great. Late static binding (coming in PHP 5.3) will be nice once it is ubiquitous.
Attributes are a way of declaratively making a statement at a more "meta" level. Because doccomments are a first class language construct in PHP (i.e. Reflection provides doccomments for you) it seemed the most appropriate place for providing additional metadata.
Have you thought about using "named" variables for this sort of functionality without interfering with the commenting system.