The main  issue is the concept behind Sinatra routing. You do not have one true params hash but different versions of that hash depending on the handler you're in.

This is how I see Sinatra routing: Prepare request, run a couple of handlers, generate response. Each handler has its own params hash, access to all helper methods and can set the response with methods like body or halt. There are special handlers that can also set the response with its return value (route handlers, error handlers), but otherwise handlers all have the same options available and only are different in when they are triggered. An incoming request is "falling" through this handlers, similar to a petri net, and triggered handlers have tools available to change the course the request takes (pass, modifying the request, etc). This is unique to Sinatra and no other Rack router I know of works that way, not even the Padrino router.

Therefore path patterns, like conditions, are criteria for triggering the specific handlers, passing those upfront would not only not fit this basic principal, but would also be a major performance impact. All incoming requests would have to be matched against all route handlers, the routing best case would be worse than the current worst case, since we would also have to check if the request patch changed after each handler and would have to reroute again. We would have to completely change the way we handle params, and all that without a use case. Or at least I'm not aware of one.

Konstantin

On Jan 4, 2011, at 04:25 , Matt Todd wrote: