Skip to content

Instantly share code, notes, and snippets.

@robashton

robashton/description.md

Last active Dec 18, 2015
Embed
What would you like to do?
Locality and Wasasbi

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.

@hhariri

This comment has been minimized.

Copy link

@hhariri hhariri commented Jun 17, 2013

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).

@robashton

This comment has been minimized.

Copy link
Owner Author

@robashton robashton commented Jun 17, 2013

Yeah - it's a trade-off and personal preference - having now experienced the far end of the spectrum in the Rails world and the other end in the JS world (CommonJS means it's pretty hard to get magic global functions in your JS), I'm pretty hardline on "knowing where stuff comes from"

Kotlin's way of building up DSLs is an interesting compromise between the two and I'm not saying I don't like it - it's still far better than global magic.

@robashton

This comment has been minimized.

Copy link
Owner Author

@robashton robashton commented Jun 17, 2013

I'm not a fan of the JS frameworks either, I prefer the modules which return a single function and have that function documented - I don't have a problem with having to look it up because we should be doing that to gain proper understanding anyway instead of relying on our tooling to simply tell us only what it wants. (Blah blah blah, I've said all this before)

@hhariri

This comment has been minimized.

Copy link

@hhariri hhariri commented Jun 17, 2013

I agree with you in terms of magic. And I favor keeping it to a minimum.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment