[dancer-users] Methods Of retrieving request parameters

[Warren Young]

On Jul 12, 2016, at 9:38 AM, Warren Young <wyml at etr-usa.com> wrote:
> 
> If your app is dependent on the path the data took to get to it, it is brittle.

Clarification: If your app *behavior* changes depending on where the data comes from, it is brittle.

I gave cat(1) as an example of doing it right.  For a more complex example, consider sqlite3.  It will accept SQL via stdin or as a parameter following the database file name.  Should it instead accept SQL via only one path?  Should its interpret the SQL differently based on the input path?  No and no.  (And for the record, I think sqlite3 should *also* accept SQL in from a named file.)

Look, I’m happy Dancer now has these new functions which let a developer restrict which sources they are willing to accept data from.  If you feel that doing so will improve your program, by all means, use these new functions.  My argument is against this apparent move to deprecate the preexisting flexible alternatives.  Reading the newer docs, one gets a sense that using param() and params() is always wrong.

I’m willing to be convinced of that, but it will take actual proof, not vague handwaving arguments.

Until then, this looks like an attempt to turn Perl into a B&D language:

  http://www.catb.org/jargon/html/B/bondage-and-discipline-language.html

And I say that as a fan of F#, a programming language that truly does have the B&D nature.  All things in their proper place.  Perl’s place is the duct tape of the Internet, and thus needs to follow Postel’s Law.