On Thu, 27 Dec 2012 02:58:29 +0000 Rik Brown <rik@rikbrown.co.uk> wrote:
Hi,
Maybe for compatibility (-ish), it could be changed so that 'splat' is still stored in the request params, but only if there is not an existing 'splat' param. This would fix the ?splat=spolsh case, and more than likely cover any existing users of params->{splat} as splat()?
I'd rather suggest removing the assignment at all. Mixing route matching mechanism with user data does not seem as good practice to me at all. Plus, this case would still be broken anyway: get qr{(.*)} => sub { my $params = params(); return ( "Hello, you have specified following parameters: " . join ", ", keys %$params ); }; i.e. it would *never* return empty list (unless "treated" with some ugly and very Dancer-specific code). Provided that the "feature" is not documented (I haven't found it anywhere), I wouldn't see it as a big deal to get rid of it (with proper alignment with release cycle, of course). (Even if there were people out there who use splat like this, and started to complain, we could give them a big warm "Welcome To The World Of Undefined Behavior(tm)" :-D) Thanks, aL. -- Alois Mahdal