Fine, so we have the following code
Routes.get("/customer',
basicAuthentication
{
log.write("Inline logging dude")
next()
},
{
response.send(customer)
}
)It's very pretty, I like the way that these blocks fall off each other. Let's compare it to
app.get('/customer',
basicAuthentication,
function(req, res, next) {
log.write("Logging")
next()
},
function(req, res) {
res.send(customer)
}
)What's the difference? Well for my money, I prefer the latter because I have req, res and next completely local to the function that is handling that particular step.
Sticking them as "members of the container class" doesn't give you a clear indication of scope or intent, they're further away from the real action and make the code slightly more opaque when you're skimming it over in a monday morning tweet.
Indidentally is this one of the reasons I'm not enjoying Ruby/Rails - lots of methods are springing into existence in the global scope "because", "magic", I prefer the explicit and the local over the magic and distant.
So that's what you meant with springing in.
Interesting though because we prefer explicit, yet often we are actually forced to look at implementation details or documentation (or the lack of it) to understand how to use functions in some of the JavaScript frameworks.
Here we're trading off that explicitness for convention and avoiding having to write request, response, next each time for every function. It's a convention we would know, much like we know that every middleware we write in the connect-based JavaScript frameworks have a convention of a function with 2 (optionally 3 params).