Just a user-experience report with traceur: the following code fails to
compile in the repl.html and command line compiler:
-
import {WrapNewObjectTransformer} from './WrapNewObjectTransformer';
export function transcode(src, url) {
var file = new SourceFile(url, src);
var reporter =
Note that in Chrome the devtools are remote and error.stack is a getter
which issues a remote method call to the backend. Only when the stack
property is accessed will the internal representation be converted to a
string. Anything else is too expensive.
A plain JS object format would be much
On Tue, Nov 12, 2013 at 8:07 PM, David Bruant bruan...@gmail.com wrote:
Le 12/11/2013 13:42, Kris Kowal a écrit :
One of the concerns with promises is that they consume exceptions that
may or may not be handled.
...
I understand the need to know when a promise has an unhandled error at
Could someone help me understand why two goals for parsing JS is a good
thing?
On Mon, Nov 11, 2013 at 3:30 PM, John Barton johnjbar...@google.com wrote:
Just a user-experience report with traceur: the following code fails to
compile in the repl.html and command line compiler:
-
import
On Thu, Dec 12, 2013 at 11:53 AM, Mark S. Miller erig...@google.com wrote:
Keep in mind that infix ! is proposed
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency for use in
ES7 to mean do this operation eventually, e.g.,
p2 = p1 ! foo(a, b);
Please do not do this ;-)
jjb
On Thu, Dec 12, 2013 at 1:41 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, Dec 12, 2013 at 2:56 PM, John Barton johnjbar...@google.comwrote:
On Thu, Dec 12, 2013 at 11:53 AM, Mark S. Miller erig...@google.comwrote:
Keep in mind that infix ! is proposed
http
On Fri, Dec 27, 2013 at 10:22 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Dec 27, 2013, at 7:27 AM, Brendan Eich wrote:
...
I thought Allen designed things so
class C {}
differed from
class C extends Object {}
so as in the first case to avoid (a) super calling Object and
On Mon, Jan 20, 2014 at 7:42 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
The draft is available at
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#january_20_2014_draft_rev_22
Big news: Promise and Module Loading/Linking. Still a few loose ends, but
we're getting
On Fri, Jan 24, 2014 at 8:49 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote:
For static language parsers there seems to be a bit of a dilemma with ES6
modules. I would appreciate a correct or hint.
Here is my
If we are asking questions: why two parse goals? Why not allow import in
Script and let it act like the code was wrapped in Loader.import() and
allow export then just ignore it? The semantics of 'var' would be changed
by appearance of 'import' just like the semantics of code changes with the
On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
I should have also included:
2A) Hopefully, overtime, the old script syntactic goal will fade from use,
and the module goal will become the norm for new code.
Now here is a reason, finally, for all the extra
, at 6:33 PM, Brendan Eich wrote:
John Barton wrote:
On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
I should have also included:
2A) Hopefully, overtime, the old script syntactic goal will fade
from use
...@mozilla.com wrote:
John Barton wrote:
The Script goal disallows 'import' and 'export' specifically to ensure
that the Script goal is inconvenient for developers and thus they are
encouraged to shift to the Module goal.
No, that's not the rationale. The reason is to avoid enabling more
What is the use case for allowing registration different modules under the
same name? IMO should be an error.
jjb
On Mon, Jan 27, 2014 at 2:32 PM, David Herman dher...@mozilla.com wrote:
On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com wrote:
So then there would be two
On Mon, Jan 27, 2014 at 2:51 PM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
1. a file extension
Talk here is not demand, and I bet we'll regret trying to add a
new one. Extensions mapped by servers to media types require
server configury, often missed
jjb
Sam
On Mon, Jan 27, 2014 at 5:45 PM, John Barton johnjbar...@google.com
wrote:
What is the use case for allowing registration different modules under
the
same name? IMO should be an error.
jjb
On Mon, Jan 27, 2014 at 2:32 PM, David Herman dher...@mozilla.com
wrote
On Mon, Jan 27, 2014 at 3:24 PM, Marius Gundersen gunder...@gmail.comwrote:
On Jan 28, 2014 12:14 AM, John Barton johnjbar...@google.com wrote:
On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
This is absolutely necessary for polyfilling
On Mon, Jan 27, 2014 at 4:57 PM, Brendan Eich bren...@mozilla.com wrote:
John Barton wrote:
It's pretty clear from NPM experience that a new suffix is not
needed for out-of-line modules. Or are you suggesting that Node.js
lacks tooling? I'm not offended, just trying
On Sat, Jan 25, 2014 at 3:31 PM, Brendan Eich bren...@mozilla.com wrote:
John Barton wrote:
The Script goal disallows 'import' and 'export' specifically to ensure
that the Script goal is inconvenient for developers and thus they are
encouraged to shift to the Module goal.
No, that's
On Thu, Jan 30, 2014 at 7:54 AM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
Generally, I've always thought of:
if (x) ... as equivalent to if (x) { ... }
let and const (and class) are block-scoped. {...} in your if (x) {...}
is a block. An unbraced consequent is not a
On Thu, Jan 30, 2014 at 10:59 AM, John Barton
That craziness is the whole point of block scoping let. ...
Give that this is the behaviour of every other block scoped language i
don’t see why this is confusing.
It's not `let` vs `var` that concerns us, it's that the statement following
On Thu, Jan 30, 2014 at 8:59 AM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
In my model
if (y) let x = 42
is equivalent to
if (y) {
let x = 42
}
and it is clear x in alert(x) is 0;
It is as clear as those invisible braces in your model's input :-P.
Come on, this
The first goal listed for ecmascript modules:
- Obviate need for globals
(http://wiki.ecmascript.org/doku.php?id=harmony:modules).
Ironically, the current proposal for module loading includes a global
System and possibly Loader. Worse, it seems like the global System is
explicitly expected
On Sat, Feb 8, 2014 at 8:11 AM, Kevin Smith zenpars...@gmail.com wrote:
Sounds both good in principle, and bad like waterfall. Waterfall is dead.
Strike the waterfall part. Still, we end up with three artifacts: a
design goals document, a prototype, and a spec. The design goals should be
On Mon, Feb 10, 2014 at 8:32 AM, David Herman dher...@mozilla.com wrote:
On Feb 7, 2014, at 8:06 AM, John Barton johnjbar...@google.com wrote:
The first goal listed for ecmascript modules:
• Obviate need for globals
(http://wiki.ecmascript.org/doku.php?id=harmony:modules
On Mon, Feb 10, 2014 at 11:24 AM, Erik Arvidsson
erik.arvids...@gmail.comwrote:
I also find the mutation of System.normalize slightly worrisome but I do
believe that good programming practice here would mean that you would call
the previous version of it after your changes. Mostly like a
How about Keyword 'let' not allowed without 'use strict' or in a module. ?
On Fri, Feb 14, 2014 at 8:18 AM, Mark S. Miller erig...@google.com wrote:
I agree that this is in some sense the least surprising. But it is so
unpleasant that I think we should instead opt for the additional surprise
(There is no spec on System, just rumors that it will be a predefined,
global instance of Loader).
As far I know the only way to use the es6 module loader without exports or
imports is to set values on 'this', the global object. I guess it's not
very different from using IIFE (function() {
then
our customization options will be limited since we won't be able to call
super methods.
On Fri, Feb 14, 2014 at 2:59 PM, David Herman dher...@mozilla.com wrote:
On Feb 14, 2014, at 12:09 PM, John Barton johnjbar...@google.com wrote:
(There is no spec on System, just rumors
On Thu, Feb 20, 2014 at 1:01 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Feb 20, 2014, at 12:53 PM, Guy Bedford wrote:
Thanks, if there is some way to detect this it may well be useful.
The use case I came across it was trying to allow ES6 modules to be
transpiled into AMD for
Well we have to make a choice. If we use Loader.prototype.Module, then
we'll get System.Module by way of System being instanceof Loader.
On Mon, Feb 24, 2014 at 10:13 AM, Juan Ignacio Dopazo jdop...@yahoo-inc.com
wrote:
The latest draft doesn't seem to specify (or I can't find) where the
On Wed, Mar 5, 2014 at 3:08 PM, Brian Terlson
brian.terl...@microsoft.comwrote:
Brendan Eich wrote:
Brian Terlson wrote:
I haven't collected much data on this so I'm not sure what the
prevalence is,
Can you try to find some sightings in the wild?
I have searched my Alexa Top 10k
You may like to take a look at how the traceur compiler (
https://github.com/google/traceur-compiler) works. It allows one to write
code like
var statement = parseStatement `${result}[${index}++] = ${expression};`;
where the ${} syntax surrounds variables from the caller that are
substituted
What is a 'mutable binding'?
On Fri, Mar 14, 2014 at 7:30 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Importing is nothing like destructuring. You import mutable bindings;
you don't do assignment. I'm very glad that different syntax is used for
each case.
On Fri, Mar 14, 2014 at 9:15 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Fri, Mar 14, 2014 at 11:04 AM, Kevin Smith zenpars...@gmail.comwrote:
Because it doesn't allow for the Assignment Expression form
(specifically, function expressions) that developers expect to be able to
On Fri, Mar 14, 2014 at 11:42 AM, David Herman dher...@mozilla.com wrote:
When you export from a module, you're exporting bindings, rather than
values. This means you can refactor between
module m from foo;
...
m.bar
and
import { bar } from foo;
...
bar
and
Notice that the eval stack trace is not very useful in the common case that
the buffer is more complex than a single line and the eval is called more
than once. For eval, new Function(), document.write(script),
document.appendChild(script), and System.module() successful debugging --
and thus
Hi Mark. I implemented the first sourceURL support, for Firebug back in
the day. It's a kludge we worked out because there was no alternative. It
forces debuggers seek the ends of buffers even if they are millions of
bytes and even if the the name does not turn out to be the one the dev was
be limiting for soureMappingUrl.
On Sun, Mar 30, 2014 at 6:25 PM, John Barton johnjbar...@google.comwrote:
Hi Mark. I implemented the first sourceURL support, for Firebug back in
the day. It's a kludge we worked out because there was no alternative. It
forces debuggers seek the ends of buffers
I was surprised to discover that in chrome at least this is valid:
var obj = {};
obj.__proto__ = undefined;
but this throws
Object.setPrototypeOf(obj, undefined);
Is it intended?
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
On Mon, Apr 7, 2014 at 10:51 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
..
It feels like everyone uses `__proto__` on daily basis while ES6 promotes
classes ... so either `__proto__` is not a real world use case, or `class`
landed for no reason, IMO.
You are correct, lots of
On Sun, May 4, 2014 at 3:00 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
+1 and as generic global utility it would be also nice to make it
compatible with all strings.
A language with modules does not need nor should it rely on stuff more
favorite features onto global. We need
I'm hoping someone can explain this result which surprises me.
If I create an object with a Proxy-ed prototype, the resulting object does
not obey .__proto__ equal Object.getPrototypeOf().
For example:
var aPrototype = {foo: 'foo'};
var handler = {
get: function(target, name, receiver) {
On Mon, May 5, 2014 at 11:44 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On May 5, 2014, at 10:40 AM, John Barton wrote:
I'm hoping someone can explain this result which surprises me.
If I create an object with a Proxy-ed prototype, the resulting object does
not obey .__proto__ equal
;
Object.getPrototypeOf(o); // Object.prototype
```
Best Regards
On Mon, May 5, 2014 at 10:40 AM, John Barton johnjbar...@google.comwrote:
I'm hoping someone can explain this result which surprises me.
If I create an object with a Proxy-ed prototype, the resulting object
does not obey
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson i...@hixie.ch wrote
What/where would be the best place to define such a system,
Github.
and how would
we hook all the specs together to use it?
Define a System object for ES6 that implements the ES6 Loader API and
extends it to dynamically
an ES6 Loader in an HTML Import, the registry will be automatically
shared).
On Tue, May 27, 2014 at 8:28 AM, Matthew Robb matthewwr...@gmail.comwrote:
On Tue, May 27, 2014 at 8:09 AM, John Barton johnjbar...@google.comwrote:
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson i...@hixie.ch wrote
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, John Barton wrote:
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson i...@hixie.ch wrote
...
and how would we hook all the specs together to use it?
Define a System object for ES6 that implements
On Tue, May 27, 2014 at 3:57 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, John Barton wrote:
I think the Loader nicely isolates these particular functions: I don't
see any urgency in standardizing them. However the delegation of the
specification of System leaves us
On Tue, May 27, 2014 at 4:51 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, John Barton wrote:
Is System something that we are expecting some non-ES spec, e.g. Fetch
or HTML, to define?
TC39 members have more than once explained that they expect some non-ES
spec
On Wed, May 28, 2014 at 3:26 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, John Barton wrote:
On Tue, May 27, 2014 at 4:51 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, John Barton wrote:
Is System something that we are expecting some non-ES spec, e.g
On Wed, May 28, 2014 at 4:20 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 28 May 2014, John Barton wrote:
Is the list that Juan described (see below) the list you had in mind?
Yes.
Cool, thanks. (It would be great if this list could be more explicitly in
the spec, for ease
On Thu, May 29, 2014 at 7:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, May 29, 2014 at 4:40 PM, John Barton johnjbar...@google.com
wrote:
My intuition is that any such plan would be vigorously opposed by the JS
community. Or perhaps vigorously ignored: browsers are falling
On Thu, May 29, 2014 at 2:31 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
- some people want to predeclare a bunch of scripts and their
dependencies, without actually downloading any of them ahead of time,
and then later, when they're
On Thu, May 29, 2014 at 4:05 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 29 May 2014, John Barton wrote:
On Thu, May 29, 2014 at 2:31 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
- some people want to predeclare a bunch of scripts
...@google.com
wrote:
On 5 June 2014 16:08, John Barton johnjbar...@google.com wrote:
On Thu, Jun 5, 2014 at 2:06 AM, Andreas Rossberg rossb...@google.com
wrote:
On 4 June 2014 23:46, John Lenz concavel...@gmail.com wrote:
I don't personally want to write sloppy mode code
If the 'module' form is left out, it can be added later. If the 'module'
form is left in, it can never be removed.
jjb
On Mon, Jun 9, 2014 at 6:39 AM, Axel Rauschmayer a...@rauschma.de wrote:
Isn't the problem, though, that default-exporting an object prevents
static checking? It feels like
On Mon, Jun 9, 2014 at 6:54 AM, Axel Rauschmayer a...@rauschma.de wrote:
On the other hand, we’ll have many pseudo-modules, which is also a barrier
against making progress later on.
Sorry, I don't understand what a pseudo-module is. Are you saying that the
core import/export system is not
On Mon, Jun 9, 2014 at 7:51 AM, Axel Rauschmayer a...@rauschma.de wrote:
I’m assuming that people will default-export objects (for
Underscore.js-like libraries). I’d call those pseudo-modules, because one
would be partially working around the module system (no load-time errors!).
Then aren't
Just another related issue: in Traceur code we use 'this' in modules to
mean 'global', because in modules we have no other way to say 'global' in
code designed to work in browsers and node.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
On Mon, Jun 9, 2014 at 9:17 AM, Mark S. Miller erig...@google.com wrote:
On Mon, Jun 9, 2014 at 9:08 AM, John Barton johnjbar...@google.com
wrote:
[...]
but ES6 is a class-based language: based on our experience the majority
of exports going forward will be classes.
Hi John, that sounds
On Mon, Jun 9, 2014 at 9:40 AM, Caridy Patino car...@gmail.com wrote:
another issue with `this` being `global` (as it is today by the specs) is
the way top level modules will be defined in a page, assuming we will have
`type=module` for scripts (which is probably were we want to be), what
The Traceur project would be interested in your issues and in a discussion
on how to improve. Improvements are easy to try.
jjb
On Wed, Jun 11, 2014 at 1:25 PM, Matthew Robb matthewwr...@gmail.com
wrote:
I have been working extensively with modules in a project that will be
going live this
I urge TC39 to assess the cost/benefit of module carefully. It brings in
a lot of issues orthogonal to JS. script is already a mess and HTML
Imports are barely a thing. Web developers need a solution to the bundling
problem for ES modules with much, much higher priority than module.
On Thu, Jun
On Thu, Jun 12, 2014 at 7:43 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I like module, simply as a better script. Whether it's worth the
cost is largely a matter of finding out what the cost is, from
implementers. I don't recall reading any opinions from them on the matter.
One unusual but interesting metric: try to find blog posts explaining
module m from 'mymodule';
vs posts explaining import. At least my attempts failed.
Basically authors who thought ES6 modules are worth explaining did not
think 'module' was worth explaining.
jjb
On Thu, Jun 12, 2014 at
On Sun, Jun 15, 2014 at 8:32 PM, Axel Rauschmayer a...@rauschma.de wrote:
I apologize for this email, but I still don’t understand the current
module design.
...
**Single-export modules.** Still missing is support for single-export
modules, which could be added as follows (the keyword
On Mon, Jun 16, 2014 at 3:42 PM, caridy car...@gmail.com wrote:
On Jun 16, 2014, at 5:41 PM, Frankie Bagnardi f.bagna...@gmail.com
wrote:
The other big concern here is that in production, very few people are
going to be loading every JavaScript file asynchronously. If there's
magic, there
On Mon, Jun 16, 2014 at 4:04 PM, caridy car...@gmail.com wrote:
I thought SPDY was, to quote wikipedia, about: reducing web page load
latency and improving web security
How does SPDY help when the issue is lots of small requests ping ponging
back and forth between client and server?
SPDY
On Mon, Jun 16, 2014 at 4:49 PM, caridy car...@gmail.com wrote:
I thought SPDY was, to quote wikipedia, about: reducing web page load
latency and improving web security
How does SPDY help when the issue is lots of small requests ping
ponging back and forth between client and server?
SPDY
. Unfortunately, there isn't a good delta compression solution
yet but I have hopes that SDCH might be made more general and standard.
On Mon, Jun 16, 2014 at 4:54 PM, John Barton johnjbar...@google.com
wrote:
On Mon, Jun 16, 2014 at 4:49 PM, caridy car...@gmail.com wrote:
I thought
Sorry to be dense, but I would appreciate more elaboration of this sentence:
On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer a...@rauschma.de wrote:
This is a key sentence in David’s proposal: “ES6 favors the single/default
export style,
What is the single/default export style? If I
On Thu, Jun 19, 2014 at 10:48 AM, Axel Rauschmayer a...@rauschma.de wrote:
On Jun 19, 2014, at 16:17 , John Barton johnjbar...@google.com wrote:
Sorry to be dense, but I would appreciate more elaboration of this
sentence:
On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer a...@rauschma.de
On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Can you develop these particular accusations?
Why would TC39 have priorities that don't align with the needs of
developers? especially on modules which are clearly one of the most awaited
feature as far as
On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I am trying to stay outside this discussion as much as I can but there is
a specific sentence that I'd like to understand:
On Fri, Jun 20, 2014 at 8:39 AM, John Barton johnjbar...@google.com
wrote
ES6 already has what you want:
_Named Exports_:
export var foo = 1;
_Single Export Object_:
export var moduleName = {
foo: 1,
bar: function() {}
};
_Single Export Function_:
export function fName() { }
And even cooler, the syntax for import is uniform,
import {foo} from
On Fri, Jun 20, 2014 at 4:17 PM, Ron Buckton rbuck...@chronicles.org
wrote:
From: John Barton [mailto:johnjbar...@google.com]
Sent: Friday, June 20, 2014 3:48 PM
ES6 already has what you want:
_Named Exports_:
export var foo = 1;
_Single Export Object_:
export var
Guy Bedford's es6-module-loader follows the Loader spec closely. I just
refactored it to create a function call `parse(load) - deps`:
https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/loader.js#L389
This location in the pipeline is pretty much where you suggest. I think
I've
On Tue, Jun 24, 2014 at 12:53 PM, Guy Bedford guybedf...@gmail.com wrote:
If it is a tools problem, it becomes a much more complex problem.
Firstly note that the promise isn't rejecting, it is resolving correctly.
That is if I have a module X:
X.js
throw this module throws;
Then:
// I have a module named `foo`.
// I don't care what `foo` is.
// Including whether or not its a namespace.
// I need make no promises about identifier `foo`.
import {bar} from './foo';
On Wed, Jun 25, 2014 at 12:52 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Wed, Jun 25, 2014 at 2:59
On Thu, Jun 26, 2014 at 7:39 AM, Axel Rauschmayer a...@rauschma.de wrote:
// my-class.js
export class MyClass {
constructor() { ... }
method() { ... }
}
// use-class.js
import { MyClass } from my-class.js;
You do have redundancy in `my-class.js` and,
+1
On Fri, Jun 27, 2014 at 6:39 AM, Matthew Robb matthewwr...@gmail.com
wrote:
My opinion is that CommonJS and AMD work today and will continue to work
into the future so we should optimize for the ideal looking forward, not
backward case when adding to the language. Loader will still be
On Sat, Jun 28, 2014 at 9:03 AM, Kevin Smith zenpars...@gmail.com wrote:
Static checking on exported members feels odd.
Static checking of imports and exports has well-known advantages and would
help the long-term viability of the language.
Enumerating these specific advantages would
Thanks Kevin. I'm going to challenge your list below, but I hope you don't
take it negatively. I want the case for the module system to be as strong
as possible.
On Sat, Jun 28, 2014 at 11:51 AM, Kevin Smith zenpars...@gmail.com wrote:
Static checking of imports and exports has well-known
On Sat, Jun 28, 2014 at 3:58 PM, Kevin Smith zenpars...@gmail.com wrote:
Static checking will be limited anyway. If you want to go this way you
should use typescript.
That's the point that I'm trying to make, shops will choose other
languages that provide more static information. We should
Let me try to restate my request for clear information on the advantages of
module bindings vs module object architectures.
The import syntax already allows pre-execution tools to collect every
module that will be accessed by a root dependent module (including some
that may not be used). This
On Mon, Jun 30, 2014 at 12:00 PM, Kevin Smith zenpars...@gmail.com wrote:
What's not clear is the advantage of module bindings form for modules.
When the world of possibilities opens up, what specific things will I see
there?
I think I'm following you now. So let's pose the question like
This seems like a bit too many issues, so let me just correct one
(important) one.
On Wed, Jul 2, 2014 at 2:09 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Wed, Jul 2, 2014 at 7:09 PM, John Barton johnjbar...@google.com
wrote:
Now, I know there are people that think
On Thu, Jul 3, 2014 at 2:31 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Tools like Traceur can support it for an easier migration path since they
already have diverged from ES.next anyway with all the annotations (for
which, off topic, I haven't seen even a proposal here yet)
In
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-instantiatesucceeded-instantiateresult-functions
,
15.2.4.5.3 InstantiateSucceeded(instantiateResult) Functions
The step number 4 reads:
-
If instantiateResult is undefined, then
Let body be the result of parsing load.[[Source]],
On Wed, Jul 9, 2014 at 1:57 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
...
I proposed (it was less of a proposal though, more an idea or an example
to spur better ideas) that we had a single dynamic exportable per each
module, and that could be an object, function, undefined
Why not something more like:
class RemappingLoader extends Reflect.Loader {
constructor(hooks, baseURL, paths) {
super(hooks);
//...
}
fetch(load) {
// ..
}
}
Reflect.global.System = new RemappingLoader(Reflect.global.System,
process.cwd() + '/', {'*': '*.js' });
The main
that but really this is ES6:
can't we do better?
jjb
- Matthew Robb
On Mon, Jul 14, 2014 at 1:53 PM, John Barton johnjbar...@google.com
wrote:
Why not something more like:
class RemappingLoader extends Reflect.Loader {
constructor(hooks, baseURL, paths) {
super(hooks
In the module system we issue
import {foo} from 'foo';
and the Loader computes an address, say foo.js, fetches the resource and
compiles it. If the content of foo.js has no dependencies, it is evaluated,
then the importer is evaluated. Yay!
Now suppose that foo.js defines a global value. Oh
...@cs.indiana.edu
wrote:
Why not:
import {} from 'foo';
or
import * as f from 'foo';
This is assuming that there are no other desired exports -- if there
are, then the case is even easier.
Sam
On Mon, Jul 14, 2014 at 8:37 PM, John Barton johnjbar...@google.com
wrote:
In the module
On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com wrote:
In Brian's case we actually need default exports. This is because the
dynamic loader can't pick up the code he has written right now in ES6.
This is how he is loading a NodeJS module in ES6:
module minimist from
module. This is the same method we have for AMD compilations at
the
moment, which seems to have been working well.
On 21 July 2014 10:17, John Barton johnjbar...@google.com wrote:
On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com
wrote:
In Brian's case we
The Loader hook callbacks all have an API defined like:
Reflect.Loader.prototype.locate ( loadRequest )
My interpretation of this description was that the callback provider should
expect the same loadRequest object in to reappear during the load pipeline
and furthermore, this being JavaScript,
Ok thanks, I see that this was added and I did not notice. (I think this
kind of creeping overspecification annoying but inevitable I suppose).
jjb
On Wed, Jul 30, 2014 at 7:20 AM, Juan Ignacio Dopazo jdop...@yahoo-inc.com
wrote:
I don't have an answer, but the metadata property of the
The spec seems inconsistent about the metadata property. The define()
function of Loader accepts options.metadata:
---
26.3.3.2Reflect.Loader.prototype.define ( name, source [ , options ] )
...
8. Let metadata be GetOption(options, metadata).
9. ReturnIfAbrupt(metadata).
10. If metadata is
1 - 100 of 169 matches
Mail list logo
