> Date: Fri, 27 Jul 2012 09:09:26 -0700
> From: bren...@mozilla.org
> To: infinte.c...@hotmail.com
> CC: sa...@ccs.neu.edu; es-discuss@mozilla.org
> Subject: Re: ES Modules: suggestions for improvement
>
> BelleveInvis wrote:
> > > Date: Tue, 24 Jul 2012 1
BelleveInvis wrote:
> > Date: Tue, 24 Jul 2012 14:11:38 -0700
> > From: bren...@mozilla.org
> > To: sa...@ccs.neu.edu
> > Subject: Re: ES Modules: suggestions for improvement
> > CC: es-discuss@mozilla.org
> >
> > Sam Tobin-Hochstadt wrote:
> &g
On Tue, Jul 24, 2012 at 5:11 PM, Brendan Eich wrote:
> Sam Tobin-Hochstadt wrote:
>
>> But I don't think we should ban people from
>> using `import *` because sometimes it's hard to reason about.
>>
>
> Just to focus on import *, here's where I am:
>
> I'm in favor of deferring (not to say cuttin
> Date: Tue, 24 Jul 2012 14:11:38 -0700
> From: bren...@mozilla.org
> To: sa...@ccs.neu.edu
> Subject: Re: ES Modules: suggestions for improvement
> CC: es-discuss@mozilla.org
>
> Sam Tobin-Hochstadt wrote:
> > But I don't think we should ban people from
> &
Sam Tobin-Hochstadt wrote:
But I don't think we should ban people from
using `import *` because sometimes it's hard to reason about.
Just to focus on import *, here's where I am:
I'm in favor of deferring (not to say cutting) import *, in order to get
ES6 modules spec'ed and avoid protracted
On Tue, Jul 24, 2012 at 1:11 PM, Claus Reinke wrote:
>>>Here I've come around to Isaac's opinion that 'import *' is a
>>>step too far. Previously, I said this is a convenient bad habit
>>>that might be left to linters. But that was based on experience
>>>with statically typed langu
[I've elided some points and comments: I was trying to summarize
what seemed to me the core issues in this discussion; if my summary
was unclear, it won't help to add more text; if my summary was clear,
but the disagreements persist, adding more text won't help, either]
Here I've come arou
Being able to access the export object from the module object enables a
pattern we use locally, which is roughly
require("myModule").configParameter = xyz;
..
exports.errorReporter, exports.configParameter are then used heavily within
the module -- normally, they are not even set by the user, b
On 24 July 2012 05:03, Claus Reinke wrote:
> Hm, I hadn't thought about that, but my intuition tells me that
> there should be an export object for every module, with just the
> exports, and that this export object should be accessible from the module
> object.
>
Being able to access the export
On the subject of 'exporting one value', there are a few things to say:
1. It's been asserted repeatedly that libraries that export 'just one
value' are a better design, but while this is excellent style in lots
of cases, I don't think a persuasive case has been made that this
should be the *only
On Sat, Jul 21, 2012 at 5:03 AM, Claus Reinke wrote:
>>> If you want to export a bag of functions, then put the functions on an
>>> object, and export the object.
>>>
>>> It *is* making it trickier to figure out how to add types and macros,
>>> but I'm less excited about those features than I am a
If you want to export a bag of functions, then put the functions on an
object, and export the object.
It *is* making it trickier to figure out how to add types and macros,
but I'm less excited about those features than I am about making our
existing problems easier to solve.
It's not trickier,
On Jul 20, 2012, at 9:23 PM, Isaac Schlueter wrote:
> On Fri, Jun 29, 2012 at 4:33 PM, David Herman wrote:
>>> var fs = require('fs')
>>> // no path here...
>>> function notCoveredByTests () {
>>> fs.open(path.resolve("yabbadabba"), ...)
>>> }
>>
>> Right.
>>
>>> How would any of this solve tha
Sorry for my long delay in responding.
On Fri, Jun 29, 2012 at 4:33 PM, David Herman wrote:
>> var fs = require('fs')
>> // no path here...
>> function notCoveredByTests () {
>> fs.open(path.resolve("yabbadabba"), ...)
>> }
>
> Right.
>
>> How would any of this solve that?
>
> Because `path` is
Strongly concur with Andreas. Citing Java is fraught beyond belief.
Andreas Rossberg wrote:
>___
>es-discuss mailing list
>es-discuss@mozilla.org
>https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss m
Right. :-)
There is indeed some clever module stuff out there. IIRC, Racket, née PLT
Scheme, goes even further than ML. Newspeak is interesting, too.
[[[Sent from a mobile device. Please forgive brevity and typos.]]]
Dr. Axel Rauschmayer
a...@rauschma.de
Home: http://rauschma.de
Blog: http://2a
On 30 June 2012 01:49, Axel Rauschmayer wrote:
> So packages are like 30% of a module system.
>
Coming from ML, I have to disagree strongly -- Java's packages are at most
3% of a module system. ;)
/Andreas
___
es-discuss mailing list
es-discuss@mozill
> In Java, they didn't even *have* a module system because classes did
> double-duty as a data abstraction, a constructor, a type definition and a
> module.
Not that it affects your arguments, but that is not entirely true. With
packages, you’ve always had a namespacing mechanism that was easy
On Jun 27, 2012, at 1:06 PM, Isaac Schlueter wrote:
> On Wed, Jun 27, 2012 at 11:51 AM, David Herman wrote:
>> That bug was particularly bad because it was *assigning* to an accidentally
>> global variable. But in my personal experience I certainly forget to import
>> common libraries like 'pat
On Thu, Jun 28, 2012 at 7:56 AM, Sam Tobin-Hochstadt wrote:
> On Thu, Jun 28, 2012 at 10:40 AM, Kevin Smith wrote:
>>>
>>>