ES Modules: suggestions for improvement

classic Classic list List threaded Threaded
78 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

ES Modules: suggestions for improvement

James Burke-5
Posted here:
http://tagneto.blogspot.ca/2012/06/es-modules-suggestions-for-improvement.html

Some of it is a retread of earlier feedback, but some of it may have
been lost in my poor communication style. I did this as a post instead
of inline feedback since it is long, it has lots of hyperlinks and it
was also meant for outside es-discuss consumption.

I am not expecting a response as it should mostly be a retread, maybe
just phrased differently. Just passing along the link in the interest
of full disclosure, maybe the rephrasing helps understand the earlier
feedback.

James
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Wrap - [related to : ES Modules: suggestions for improvement]

Aymeric Vitte
Starting a new thread in order not to interfer but it is related (as far
as I understood modules implementation is let to the appreciation of
people that will develop it).

See https://gist.github.com/2995641

Since everybody is spending his time to wrap and try to separate things
while trying to insure at the same time bindings to the global or to a
"new" global, maybe it would be good to have a built-in structure for
that, this suggestion is an example and a compromise with the concept of
modules's complete separation which is not always easy to manipulate and
does not really allow to use directly as such frameworks not designed as
modules.

Le 26/06/2012 06:24, James Burke a écrit :

> Posted here:
> http://tagneto.blogspot.ca/2012/06/es-modules-suggestions-for-improvement.html
>
> Some of it is a retread of earlier feedback, but some of it may have
> been lost in my poor communication style. I did this as a post instead
> of inline feedback since it is long, it has lots of hyperlinks and it
> was also meant for outside es-discuss consumption.
>
> I am not expecting a response as it should mostly be a retread, maybe
> just phrased differently. Just passing along the link in the interest
> of full disclosure, maybe the rephrasing helps understand the earlier
> feedback.
>
> James
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

--
jCore
Email :  [hidden email]
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

David Bruant-5
In reply to this post by James Burke-5
Also relevant to this thread, post on the same topic by Isaacs (node.js
lead) : http://blog.izs.me/post/25906678790/on-es-6-modules

David

Le 26/06/2012 06:24, James Burke a écrit :

> Posted here:
> http://tagneto.blogspot.ca/2012/06/es-modules-suggestions-for-improvement.html
>
> Some of it is a retread of earlier feedback, but some of it may have
> been lost in my poor communication style. I did this as a post instead
> of inline feedback since it is long, it has lots of hyperlinks and it
> was also meant for outside es-discuss consumption.
>
> I am not expecting a response as it should mostly be a retread, maybe
> just phrased differently. Just passing along the link in the interest
> of full disclosure, maybe the rephrasing helps understand the earlier
> feedback.
>
> James
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

John J Barton
As I understand it, two issues drive the need for standardization of modules:
  1) we want one environment for all JS,
  2) to move beyond the limitations of RequireJS and CommonJS requires parsing, and that is considered too expensive for library implementations.
The first point is obvious, the second one is implicit in the blog posts by Isaac and James.

In other words, I gather that Isaac, James and others believe that there exists a parser based dependency analysis solution that does not require the significant new ES harmony syntax.  Since we have Traceur, esprima-harmony and similar transpilers, we can try ES-Harmony vs TBD-better-option.  But we need said option to show up.

jjb

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Thaddee Tyl
On Tue, Jun 26, 2012 at 10:12 AM, John J Barton
<[hidden email]> wrote:
> As I understand it, two issues drive the need for standardization of
> modules:
>   1) we want one environment for all JS,
>   2) to move beyond the limitations of RequireJS and CommonJS requires
> parsing, and that is considered too expensive for library implementations.
> The first point is obvious, the second one is implicit in the blog posts by
> Isaac and James.


Another point that I believe Isaac is making is that too much syntax
is likely to confuse developers and allowing certain features, such as
nested modules or `import *`, can be harmful to programmer efficiency
in the long term, if used.

For the purpose of discussion, I made a gist [0] of Isaac's proposal.
Most of the module examples [1] are there.

  [0] https://gist.github.com/2997742
  [1] http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples

Isaac, feel free to correct it.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

David Bruant-5
In reply to this post by David Bruant-5
Le 26/06/2012 16:44, David Bruant a écrit :
Also relevant to this thread, post on the same topic by Isaacs (node.js lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
"Furthermore, let already gives us destructuring assignment. If a module exports a bunch of items, and we want several of them, then do var {x,y,z} = import 'foo' or some such."
=> Excellent idea. That combined with the single export idea reduces the amount of new syntax to introduce.
The Module proposal has a local renaming feature which I think should be kept:
Initial proposal:
    import { draw: drawShape } from shape;
    import { draw: drawGun } from cowboy;
Could become:
    let {draw: drawShape} = import './shape.js'
    let {draw: drawGun} = import './cowboy.js'

I would actually reverse the order:
    let {drawShape: draw} = import './shape.js'
    let {drawGun: draw} = import './cowboy.js'
But that's a matter of taste.

By the way, the local renaming for destructuring is relevant regardless of modules.

    function f(point1, point2){
        let {x1:x, y1:y} = point1,
             {x2:x, y2:y} = point2;
        // ...
    }




I'd like to answer on this post proposal as it brings some interesting points, but also raises some questions:

3) Loader.define(<path>, <program text>) defines a module at the specified <path>, with the <program text> contents. That <program text> is statically analyzed for any import statements.
=> I don't understand this part. Why would you need to define a module at a specified path? Either there is a JS file at this path already or there is none, no?

4) Whenever an import <path> is encountered in <program text> then the Loader.resolve(requestPath, callerPath, callback) is called. This method should return a fully qualified path. If this method returns boolean true, then it will not be considered resolved until the callback is called. (The argument to the callback is the string path.) If it does not return true, and does not return a string path, then this is an error, and throws.
=> If syntax calls the Loader.resolve method, I don't understand who sets the callback.
Regardless, Loader.resolve(requestPath, callerPath) seems like it could be a synchronous operation without too big of a performance penalty.
I disagree with the idea of calling the dynamic value of Loader.resolve on syntax. We have seen that this resulted in potential attack (like when the dynamic Array constructor was used in Chrome's JSON.parse).

"For security, the Loader object could be frozen with Object.freeze to prevent additional changes."
=> This is not enough. People shouldn't have to opt-in for security, mostly because they don't do it. I woud call for security by default here and having "import <path>" call the built-in Loader.resolve instead of the dynamic one.
If people want to override the Loader API, they would have to forget about syntax. Or a new syntax could be introduced, making clear that it's dangerous. Maybe something like "importDyn".



5) Once a module is resolved to a full path string, then Loader.load(fullPath, callback) is called. callback should not be called until Loader.define(fullPath, contents) is called. This should be called at most once for any given fullPath. (Is the callback even necessary? Why not just wait for Loader.define and throw any errors encountered?)
=> I guess I understand better Loader.define, but I intuit that the API could be reworked to remove it.

6) The Loader.main(fullPath) method executes the module referenced by fullPath (which must have already been defined), as well as evaluating each of the modules that it imports.
=> It seems that the method should be called Loader.load, here, but that's a nitpick

7) Within a module, the export <expression> statement marks the result of <expression> as the exported value from the module. There can be at most one export statement in a module, and the exported expression is the module’s export. To export more than one thing, export an object with more than one thing on it.
=> This and destructuring. I love the combinaison.

    Modules export a single value. Exporting a second time throws.
=> This can even be made a parse-time error.

    Maybe this is not a valid cause for syntax addition. I’m not sure. There are hairy problems around cyclic dependencies, so it’s worth at least having the option to address with static magic that has not yet been fully imagined.


8) The global object within a module context is equivalent to Object.create(<global>) from the main global context. (The important thing is that leaks aren’t leaky outside the module, but for example, x typeof Error still works, because it uses the same Error function.)
9) If a module does not contain an export statement, then its global object is its export. This is to provide support for legacy modules that create a global object (such as jQuery) rather than using an export statement. (Too magical? Probably. Also, what about having exports inheriting from global is weird. Is there a simpler way to make existing libs place nicely with this approach?)
=> Making the global scope of a file the implicit export object sounds like an excellent idea. I concur that Object.create(<global>) may not be the best idea. Recently, Allen introduced different ideas to deal with the global environment [1]. Maybe there are things to leverage here.
Still, not having syntactical "export" statements requires execution to know what is being exported and may delay error detection. Maybe that's a good thing to have both: either benefit from some early-error mechanism or painlessly leverage existing code.

David

[1] https://mail.mozilla.org/pipermail/es-discuss/2012-May/022627.html

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Isaac Schlueter
In reply to this post by Thaddee Tyl
The linked blog post is a very rough cut of where my thoughts are on
the subject.  Expect changes and cleanup.  It does not represent a
fully-baked (or even half-baked) idea, but more like a general
direction.

I expect to clean it up and propose something at least half-baked to
this list soon, incorporating some of the feedback that I've gotten
from that blog post.

On Tue, Jun 26, 2012 at 11:34 AM, Thaddee Tyl <[hidden email]> wrote:
> Another point that I believe Isaac is making is that too much syntax
> is likely to confuse developers

Developers are very good at getting un-confused by new syntax, and
newbies are very good at becoming less new.  That's not *much* of a
hazard.

The bigger hazard is that we can't remove the syntax we add, and
historically, humans don't have a perfect track record at expecting
consequences, so we should try to reduce additions to the smallest set
possible to deliver the more important functionality.  In other words,
if some % of what we do is a mistake, we halve our mistakes by doing
half as much.  If we can focus what we do on the things that are very
essential to what we need, we can probably beat those odds :)

> and allowing certain features, such as
> nested modules or `import *`, can be harmful to programmer efficiency
> in the long term, if used.

Bingo.  Favoring the `exports` object instead of `module.exports` was
a mistake.  Implementing `import *` in Python and Java was a mistake.

Copying existing successful systems is good, but we should avoid
copying their mistakes if possible.


> Isaac, feel free to correct it.

Will do.  Probably not until after NodeConf early next week.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Kevin Smith-21
Hi Isaac,

I share some of your concerns as well.  I like the idea of "import" just returning an object, which can be destructured using let.  I also like the idea of eliminating the "import *" syntax.  However, I think that dynamic exports ("export <expression>") might not be as useful as it seems.

In my modules, I use the "export <expression>" form for the following reasons:

1.  When I want to export a single function (perhaps a constructor), and I don't want importers to unnecessarily repeat the function name:

    var MyClass = require("MyClass").MyClass; // Boo!
    var MyClass = require("MyClass"); // Better!

2.  When I want to rename an export:

    function shortName() { ... }

    module.exports = { longName: shortName };

3.  When I want to group together the exported API, instead of having it spread across the file:

    function A() { ... }
    function B() { ... }
    function C() { ... }

    module.exports = { A: A, B: B, C: C };

For case 1, destructuring allows us to eliminate the repetition:

    let { MyClass } = import "MyClass.js";

A static multiple export syntax ("export { ... }") would work just fine for cases 2 and 3:

    export {
      longName: shortName,
      A,
      B,
      C
    };

Are there any other cases where dynamic exports are useful?

- Kevin


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Wes Garland
On 26 June 2012 16:45, Kevin Smith <[hidden email]> wrote:
Hi Isaac,

I share some of your concerns as well.  I like the idea of "import" just returning an object, which can be destructured using let.  I also like the idea of eliminating the "import *" syntax.  However, I think that dynamic exports ("export <expression>") might not be as useful as it seems.

In my modules, I use the "export <expression>" form for the following reasons:

1.  When I want to export a single function (perhaps a constructor), and I don't want importers to unnecessarily repeat the function name:

    var MyClass = require("MyClass").MyClass; // Boo!
    var MyClass = require("MyClass"); // Better!

var { MyClass } = require("MyClass");  // Best!

Best of both worlds!   My code is full of this.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Aymeric Vitte
In reply to this post by Isaac Schlueter

Le 26/06/2012 20:54, Isaac Schlueter a écrit :
> The linked blog post is a very rough cut of where my thoughts are on
> the subject.  Expect changes and cleanup.  It does not represent a
> fully-baked (or even half-baked) idea, but more like a general
> direction.
>
> I expect to clean it up and propose something at least half-baked to
> this list soon, incorporating some of the feedback that I've gotten
> from that blog post.
...
>
> If we can focus what we do on the things that are very
> essential to what we need, we can probably beat those odds :)
>
Regarding modules I don't know right now what would be the best in terms
of syntax.

Node.js's way is good, except the "transitive dependency issue"
mentioned  in your post which in some cases indeed can cause problems.

I had some hard time to get used to this commonjs/node.js way of
separating modules which can not interact between each others, but now I
don't find it bad (even good).

What I find bad (1) is the need of VMs, let's take node.js's one, it's
calling c++ stuff, calling itself js's stuff, and at the end things are
coming back to js (with some imperfections like node.js's VM not binding
things correctly in some cases)

And what I find bad (2) is that the fact that a module could be a normal
web js code (ie not a module, the web is composed of js code, not
modules) seems to be minimized, and (3)  why should we continue to load
cross-domain scripts via the <script ..> tag using onload to get the
result (normal browsers) or onreadystatechange (abnormal browser) and
then process it via global variables ? Using xhr for example (var
code=xhr_result(xxx);eval(code)), this breaks the same origin policy but
it's already broken by the capability of inserting scripts (then I am
not sure about your proposal "In Web Browsers" with <script..>).

And what I find bad (4) is the impossibility of wrapping things as I
describe here https://gist.github.com/2995641 (maybe impossible, but at
least it shows the idea, and the need) instead of being forced to
transform js code into modules and play with globals, bindings and clone
stuff.


--
jCore
Email :  [hidden email]
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Wes Garland
On 26 June 2012 18:36, Aymeric Vitte <[hidden email]> wrote:
Node.js's way is good, except the "transitive dependency issue" mentioned  in your post which in some cases indeed can cause problems.

Does Node not handle transitive dependencies per CommonJS Modules/1.0?
 
What I find bad (1) is the need of VMs, let's take node.js's one, it's calling c++ stuff, calling itself js's stuff, and at the end things are coming back to js (with some imperfections like node.js's VM not binding things correctly in some cases)

Can you explain this in more detail?  I don't really understand what you're getting at .




--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Isaac Schlueter
On Tue, Jun 26, 2012 at 4:48 PM, Wes Garland <[hidden email]> wrote:
> On 26 June 2012 18:36, Aymeric Vitte <[hidden email]> wrote:
>>
>> Node.js's way is good, except the "transitive dependency issue" mentioned
>>  in your post which in some cases indeed can cause problems.
> Does Node not handle transitive dependencies per CommonJS Modules/1.0?

Yes, node handles transitive dependencies via unfinished objects, much
like the old CommonJS Modules/1.0 style.

However, it's generally better to return a single thing from a module
if possible, rather than a bunch of stuff on an object.  We use
`module.exports` to accomplish that, and it's mostly good, but it
doesn't handle cycles well.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Brendan Eich-2
In reply to this post by David Bruant-5
David Bruant wrote:
> Le 26/06/2012 16:44, David Bruant a écrit :
>> Also relevant to this thread, post on the same topic by Isaacs
>> (node.js lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
> "Furthermore, |let| already gives us destructuring assignment. If a
> module exports a bunch of items, and we want several of them, then do
> |var {x,y,z} = import 'foo'| or some such."
> => Excellent idea. That combined with the single export idea reduces
> the amount of new syntax to introduce.

Declarations can nest under control flow constructs, but import or
module dependencies must be prefetched. They're static.

   if (some_rare_condition()) { let x = import "m"; ... }

either always prefetches "m", which does not say what is meant; or it
nests an event loop, violating run-to-completion, which is not going to
happen.

> The Module proposal has a local renaming feature which I think should
> be kept:
> Initial proposal:
>     import { draw: drawShape } from shape;
>     import { draw: drawGun } from cowboy;
> Could become:
>     let {draw: drawShape} = import './shape.js'
>     let {draw: drawGun} = import './cowboy.js'
>
> I would actually reverse the order:
>     let {drawShape: draw} = import './shape.js'
>     let {drawGun: draw} = import './cowboy.js'
> But that's a matter of taste.

No, you can't so reorder, it's not a matter of taste. Destructuring is
the dual <http://en.wikipedia.org/wiki/Dual_%28category_theory%29> of
structuring.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

David Bruant-5
Le 27/06/2012 10:31, Brendan Eich a écrit :

> David Bruant wrote:
>> Le 26/06/2012 16:44, David Bruant a écrit :
>>> Also relevant to this thread, post on the same topic by Isaacs
>>> (node.js lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
>> "Furthermore, |let| already gives us destructuring assignment. If a
>> module exports a bunch of items, and we want several of them, then do
>> |var {x,y,z} = import 'foo'| or some such."
>> => Excellent idea. That combined with the single export idea reduces
>> the amount of new syntax to introduce.
>
> Declarations can nest under control flow constructs, but import or
> module dependencies must be prefetched. They're static.
>
>   if (some_rare_condition()) { let x = import "m"; ... }
>
> either always prefetches "m", which does not say what is meant;
True.
It could be considered to allow 'let x = import "m";' only at the top level.
But if it's the case, having a specific lexical form makes clearer that
it's a module import and not a regular assignment.

> or it nests an event loop, violating run-to-completion, which is not
> going to happen.
Event loops and run-to-completion aren't even part of ECMAScript, so I
wouldn't allow myself to think about such a thing.
Also having played with nested event loops in Firefox chrome code, I'm
not really sure they're a good idea the way they are currently designed
at least.

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Brendan Eich-2
David Bruant wrote:

> Le 27/06/2012 10:31, Brendan Eich a écrit :
>> David Bruant wrote:
>>> Le 26/06/2012 16:44, David Bruant a écrit :
>>>> Also relevant to this thread, post on the same topic by Isaacs
>>>> (node.js lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
>>> "Furthermore, |let| already gives us destructuring assignment. If a
>>> module exports a bunch of items, and we want several of them, then
>>> do |var {x,y,z} = import 'foo'| or some such."
>>> => Excellent idea. That combined with the single export idea reduces
>>> the amount of new syntax to introduce.
>>
>> Declarations can nest under control flow constructs, but import or
>> module dependencies must be prefetched. They're static.
>>
>>   if (some_rare_condition()) { let x = import "m"; ... }
>>
>> either always prefetches "m", which does not say what is meant;
> True.
> It could be considered to allow 'let x = import "m";' only at the top
> level.
> But if it's the case, having a specific lexical form makes clearer
> that it's a module import and not a regular assignment.

The other point people seem to miss about import as a special binding
form is not just that it can be restricted grammatically to be
control-insensitive by construction: it's that static export vs. import
checking can be done to catch typos.

This is a significant point, but it's either missed or assumed
insignificant. I think we should have a stand-up argument about it.
Static module systems are static, in dependency prefetching, in binding,
and in export vs. import checking.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

David Bruant-5
Le 27/06/2012 11:09, Brendan Eich a écrit :

> David Bruant wrote:
>> Le 27/06/2012 10:31, Brendan Eich a écrit :
>>> David Bruant wrote:
>>>> Le 26/06/2012 16:44, David Bruant a écrit :
>>>>> Also relevant to this thread, post on the same topic by Isaacs
>>>>> (node.js lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
>>>> "Furthermore, |let| already gives us destructuring assignment. If a
>>>> module exports a bunch of items, and we want several of them, then
>>>> do |var {x,y,z} = import 'foo'| or some such."
>>>> => Excellent idea. That combined with the single export idea
>>>> reduces the amount of new syntax to introduce.
>>>
>>> Declarations can nest under control flow constructs, but import or
>>> module dependencies must be prefetched. They're static.
>>>
>>>   if (some_rare_condition()) { let x = import "m"; ... }
>>>
>>> either always prefetches "m", which does not say what is meant;
>> True.
>> It could be considered to allow 'let x = import "m";' only at the top
>> level.
>> But if it's the case, having a specific lexical form makes clearer
>> that it's a module import and not a regular assignment.
>
> The other point people seem to miss about import as a special binding
> form is not just that it can be restricted grammatically to be
> control-insensitive by construction: it's that static export vs.
> import checking can be done to catch typos.
>
> This is a significant point, but it's either missed or assumed
> insignificant. I think we should have a stand-up argument about it.
> Static module systems are static, in dependency prefetching, in
> binding, and in export vs. import checking.
Import checking is definitely a feature that's worth it, but Isaacs idea
to being able to import jQuery (or any library of course) as is by
having the module global scope into the "export object" without
polluting the actual global object seems to is definitely a win.
Being able to import existing libraries as modules without changing a
bit of the library, without even having to read it or worry about global
leaks is a strong win in my opinion. It's worth not having the typo
check for this particular case.
Import checking can still be added afterward.

David
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Brendan Eich-2
David Bruant wrote:
> Import checking is definitely a feature that's worth it, but Isaacs
> idea to being able to import jQuery (or any library of course) as is
> by having the module global scope into the "export object" without
> polluting the actual global object seems to is definitely a win.

That's maybe a win, but we don't use JQuery that way today. Speculating
about future usability is perilous. We'd need to implement and test, but
see below for some questions to answer first.

If it's important, then people can build such a system using loaders.
But it's at this point completely undemonstrated that exposing JQuery's
few top-level bindings in an imported object beats (for usability,
simplifying old vs. new clients, or any other measure) modifying JQuery
to export those bindings and then importing what the client uses.

> Being able to import existing libraries as modules without changing a
> bit of the library, without even having to read it or worry about
> global leaks is a strong win in my opinion. It's worth not having the
> typo check for this particular case.

Either way, there's a different client code obligation from today's pattern.

It's true you can use today's JQuery as is, but why would you use a new
client API or syntax and require only new browsers or else
trans-compilation? What's the benefit?

> Import checking can still be added afterward.

How?

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Aymeric Vitte
In reply to this post by Wes Garland

Le 27/06/2012 01:48, Wes Garland a écrit :
 

What I find bad (1) is the need of VMs, let's take node.js's one, it's calling c++ stuff, calling itself js's stuff, and at the end things are coming back to js (with some imperfections like node.js's VM not binding things correctly in some cases)

Can you explain this in more detail?  I don't really understand what you're getting at .
It's a paradox for me, we should be able to handle "VMs" as something builtin without having to do plenty of clone manipulations, using fake or temporary globals, using tricks to reproduce the bindings, extracting and processing stuff from the code to execute, freezing things etc... I give some examples in the gist link I have provided (node, cajaVM, shadow), in the case of node it's even more strange since VM is a c++ module that is internally using js, it's not a critic, that's the way it is, but again we should be able to handle this more simply in js

Regarding modules, I can not believe I am the only one to want to load scripts (and not modules) as I described, so I can load and execute them when and where I want, again example in the gist, modules/scripts are complementary
-- 
jCore
Email :  [hidden email]
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Kevin Smith-21
In reply to this post by Brendan Eich-2
The other point people seem to miss about import as a special binding form is not just that it can be restricted grammatically to be control-insensitive by construction: it's that static export vs. import checking can be done to catch typos.

As long as the exported names are static, it's possible to catch typos using Isaac's form as well though, right?

- Kevin

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES Modules: suggestions for improvement

Isaac Schlueter
I think a stand-up fight about this sounds wonderful.

I am not at all convinced that typo-checking is anywhere near worth
the price tag, or is even a problem.  Most of the alleged needs for
type-checking are a bit dubious to me; that's not really what JS is
all about.

It would be great for one of the static-export proponents to catalog
some current problems in the wild today that this would address, with
code examples that use modern module systems.


Re: Conditional Importing

Only allowing `import` at the top level sounds like an ok idea, but
I'm not so sure it's necessary.  Consider the current require() style:

if (some_rare_condition()) {
  foo = require('foo')
}

In requirejs and browserify the 'foo' module will be *defined*, but
never loaded (ie, prefetched, evaluated for deps, bundled, etc).  In
Node, it won't be read from the disk or evaluated (but if it's not
there ON the disk, you'll have problems eventually, which is
conceptually equivalent to having already been fetched, but without
the pre-run safety check.)

if (some_rare_condition()) {
  foo = import 'foo'
}

could be treated similarly.  There is an import statement, so resolve
it and define it.  However, it's never actually evaluated/run until
the first time the condition is hit, so the program text will be
parsed for `import`s, but never actually executed.

I am not aware of this being a surprise to many people in the current systems.


> It's true you can use today's JQuery as is, but why would you use a new client API or syntax and require only new browsers or else trans-compilation? What's the benefit?

I'm confused.  Isn't `module "jquery" { ... $teh.Codez() ... }`
already going to require only new browsers, as well as code editing or
trans-compilation?  Why is that less onerous than a new API or html
tag, especially when the tag can desugar to the API?

But, that being said, as I mentioned in the cited blog post,
auto-exporting the global is a bit weird, at least.  Making changes to
old libraries is costlier than we tend to think, but usually not
prohibitively so (and when it is, we just write new libraries).


I definitely agree that speculating about the future is hazardous,
which is exactly why I think that the module specification (and all ES
specs, actually) should focus on the problems we have today, and aim
to deliver value to today's programs.  We should look at current
common problems, and ask, "What is the minimum change to the
language's semantics and syntax that will make *this problem* go away,
without causing new problems, or preventing other solutions?"
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
1234