github at esdiscuss.org (2013-07-12T02:27:02.823Z)
On 22 April 2013 15:27, Quildreen Motta <quildreen at gmail.com> wrote:
> 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.
Just to be clear, what I suggested was having a single global
convention for the name of the 'anonymous' export in every module, say
,"it". No need to know the "internals" of anything. Your Node example,
> ```js
> var json_request = require('json-request-middleware')
> var json_output = require('json-output-middleware')
> ```
would e.g. become
```js
import it as json_request from 'json-request-middleware'
import it as json_output from 'json-output-middleware'
```
(and similarly, on the export side).
> 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):
>
> ```js
> import dom as domFactory
> var dom = domFactory(cssSelector, eventBridge)
> ```
In the syntax Dave proposed that would actually be:
```js
import default domFactory from dom
var dom = domFactory(cssSelector, eventBridge)
```
Is that so notably better than
```js
import it as domFactory from dom
var dom = domFactory(cssSelector, eventBridge)
```
to be worth adding the new syntax? (And semantics, I presume, because
Dave hasn't actually told us how the "anonymous" export would be
distinguished internally.)
On 22 April 2013 15:27, Quildreen Motta <quildreen at gmail.com> wrote: > 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. Just to be clear, what I suggested was having a single global convention for the name of the 'anonymous' export in every module, say ,"it". No need to know the "internals" of anything. Your Node example, > var json_request = require('json-request-middleware') > var json_output = require('json-output-middleware') would e.g. become import it as json_request from 'json-request-middleware' import it as json_output from 'json-output-middleware' (and similarly, on the export side). > 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) In the syntax Dave proposed that would actually be: import default domFactory from dom var dom = domFactory(cssSelector, eventBridge) Is that so notably better than import it as domFactory from dom var dom = domFactory(cssSelector, eventBridge) to be worth adding the new syntax? (And semantics, I presume, because Dave hasn't actually told us how the "anonymous" export would be distinguished internally.) /Andreas