[dancer-users] Splat pollution of params' space

[Alois Mahdal]

On Thu, 27 Dec 2012 02:58:29 +0000
Rik Brown <rik at 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