> Someone, please show me code that the new keywords makes better.

Here's one I prepared earlier:

https://github.com/PerlDancer/Dancer2/pull/1213/commits/0745c2797f477401bc9ef6ef1c387f4330e9e06b
 

I'm not necessarily sold on a *don't use params* stance but it's definitely a 
potential source of subtle bugs if you are going to be passing on the 
parameters on. Or indeed if there is any logic outside of the route handler 
(e.g. middleware, maybe hooks) that doesn't use params or inspect all three 
sources.

Daniel


-----Original Message-----
From: dancer-users [mailto:[email protected]] On Behalf Of Warren 
Young
Sent: 12 July 2016 16:02
To: Perl Dancer users mailing list
Subject: Re: [dancer-users] Methods Of retrieving request parameters

On Jul 11, 2016, at 3:29 AM, Dave Cross <[email protected]> wrote:

> The more explicitly-named methods are definitely safer. You really want to 
> know where your parameters are coming from.

I’m still waiting for someone to justify that stance with more than confident 
prose assertions.  Someone, please show me code that the new keywords makes 
better.

If I’ve defined a route:

    get '/foo' => sub {
        my $bar = param 'bar';

        ...

…what practical difference does it make if my caller sends me the parameters in 
the URL or in the request body?  I’ve received a “bar” parameter, end of story. 
My program is satisfied.

The only case I can see is if you have two or more different ways to pass a 
given parameter, and they have different semantic meaning:

    get ‘/foo/:bar?' => sub {
        my $bar1 =  body_parameters->get('bar');
        my $bar2 = query_parameters->get('bar');
        my $bar3 = route_parameters->get('bar');
        
        if (defined $bar1) {
             # do one thing
        }
        elsif (defined $bar2) {
             # do something completely different
        }
        elseif (defined $bar3) {
             # do something different from both above options
        }
        else {
             # emit flying monkeys
        }
    };

I submit that the above is horrible coding style, and no amount of keyword 
redesign in Dancer is going to fix the fundamental problem, that being PBD.

    http://www.catb.org/jargon/html/P/PBD.html
_______________________________________________
dancer-users mailing list
[email protected]
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
_______________________________________________
dancer-users mailing list
[email protected]
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

Reply via email to