Fwd: Modules: Curly Free

Quildreen Motta quildreen at gmail.com
Mon Apr 22 06:27:19 PDT 2013


On 22 April 2013 09:18, Andreas Rossberg <rossberg at google.com> wrote:

> On 21 April 2013 04:15, David Herman <dherman at mozilla.com> wrote:
> > On Apr 20, 2013, at 5:17 AM, Brendan Eich <brendan at mozilla.com> wrote:
> >
> > Moreover, "ad-hoc" seems to suggest some sort of arbitrariness, as if
> it's not well-motivated. It is in fact well-motivated, by a real
> requirement that otherwise requires a manual design pattern -- on the part
> of both the creators *and* the clients of libraries, note well! In fact,
> I've seen the design pattern arise in practice in other languages. And yet
> in existing JS module systems, no such pattern is required of a library's
> clients. (The clients are of course the important case. Yet another
> instance of the applicability of Mr. Spock's solution!)
>
> I'm sorry, but I'm afraid this is one of these moments where I have no
> idea what the heck you guys are talking about. ;)  It is a trivial
> naming convention, for a single identifier! How is a single name
> possibly more difficult to learn or remember than any additional piece
> of syntax, however simple that may be? And how is calling it a "manual
> design pattern" less hyperbolic?
>

The fact that explicitly naming things in your modules requires the user to
know the internal structure of the module they're dealing with when that
isn't exactly necessary adds some complexity (or a "manual design
pattern"). Patterns are nasty, patterns are eugh.

At any rate, take these two use cases:

First, someone publishes a module that is intended to use as a middleware
for processing incoming HTTP requests. Middlewares are just advice
functions that wrap around the main handler to do transformations to the
request object — they take one function, return a new function. These
things are composed using plain old function composition:

Say, in Node I have a library that works that way, and I want to process
JSON requests and output, which are two different modules. I would use
something like this:

var json_request = require('json-request-middleware')
var json_output = require('json-output-middleware')

compose(json_output, json_request)(http_handler)(80)

Now, if the modules are required to explicitly name their exports, I'd have
to remember what kind of name the author of that module used when I'm
really only interested in the module itself (or the middleware it is trying
to share with me):

import jsonRequestMiddleware from jsonRequestMiddleware
import jsonOutputMiddleware from jsonOutputMiddleware

compose(jsonOutputMiddleware, jsonRequestMiddleware)(http_handler)(80)

So far, so good. Nothing that a good memory (which I don't have, btw) can't
deal with. Just a little more of cognitive load can't hurt. Problems arise
when you start having a bunch of these modules (and with the Node
philosophy that's 99% of the cases) *and* somehow those authors have chosen
similar names for their exports. Now you need to remember the name they've
used *and* bind it to another name to solve a conflict, when you could just
be doing the binding anyways.

The second use case would be encoding parametric modules by a single
function exports. In this case, you need to unwrap the module anyways
before you can use it, because it depends on external stuff that you as the
client have to provide. Again, this maps rather straight-forwardly to
first-class modules in CommonJS.

var dom = require('dom')(cssSelector, eventBridge)
dom.query('.foo').on('click', function(ev) { /* event is sanitised here by
the eventBridge library */ })

This doesn't map that well to current ES modules because they're second
class (unless I've been so out of the loop that I've missed they being
promoted):

import dom as domFactory
var dom = domFactory(cssSelector, eventBridge)

Requiring people to name that explicitly creates again unnecessary "hops"
that might be error prone, and deviate from the purposes of the module.
IMHO, that does mean things lose a certain clarity, but on the other hand
it could be argued that it just forces people to write code using different
design choices. This could mean that you fork the community because you
can't provide what one expects from a particular module system, and you end
up with a messier state than the current CommonJS/AMD/whateverElse.


Quildreen "Sorella" Motta  (http://killdream.github.com/)
— JavaScript Alchemist / Minimalist Designer —
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130422/6dcc9dcb/attachment.html>


More information about the es-discuss mailing list