al
> `asap`-like dispatcher.
> --scott
>
> On Mon, Jun 26, 2017 at 8:20 AM, Calvin Metcalf <calvin.metc...@gmail.com>
> wrote:
>
>> Kris, you're conflating macrotasks and microtasks [1]. This has come up a
>> couple times before and there have been issues rai
Kris, you're conflating macrotasks and microtasks [1]. This has come up a
couple times before and there have been issues raised by browser
venders[2][3].
1. https://github.com/YuzuJS/setImmediate#macrotasks-and-microtasks
2. https://bugzilla.mozilla.org/show_bug.cgi?id=686201
3.
looks like you missed the part of the chapter that convered this :)
http://exploringjs.com/es6/ch_modules.html#_imports-and-exports-must-be-at-the-top-level
but the tl;dr is imports are statically resolved before runtime and so must
be at the top level outside of any sort of block or function.
I've done some work on this (https://github.com/calvinmetcalf/set.up),
symmetrical difference, compliment and xor would also be helpful
On Sun, May 29, 2016, 9:13 AM Michał Wadas wrote:
> I have written proposal for new Set.prototype methods.
>
>
node crypto is asynchronous or sync and it returns a buffer of binary data
uint8's are just the default way of that node buffers represent data
On Tue, Dec 1, 2015, 2:20 PM Michał Wadas wrote:
> As we all know, JavaScript as language lacks builtin randomness related
>
Not just you
http://downforeveryoneorjustme.com/wiki.ecmascript.org
On Sat, Oct 10, 2015, 9:52 AM Mark S. Miller wrote:
> Seems to be down. Not answering pings.
>
> --
> Cheers,
> --MarkM
> ___
> es-discuss mailing list
>
Neither node.js/iojs nor nginx. Though nginx supports spdy and there is a
http2 module for node but it isn't compatible with express.
On Fri, Apr 17, 2015, 2:31 AM medikoo medikoo+mozilla@medikoo.com
wrote:
Thanks for clarifications,
Still after reading your comments I have a feeling that
This came up in iojs, did not go over well.
https://github.com/iojs/io.js/issues/1043
On Fri, Apr 17, 2015 at 1:11 PM Domenic Denicola d...@domenic.me wrote:
One thing I'm surprised nobody has brought up yet is that global would
be an incorrect name in the case of browsers. The actual global
this seems like a footgun and has tripped people up in the wild
https://twitter.com/jankrems/status/544645776518184960
On Mon Jan 05 2015 at 2:05:52 PM Caitlin Potter caitpotte...@gmail.com
wrote:
In the implementations I checked, this is actually allowed, but it's
parsed as a label instead
It should throw a static error, the loader is where this is specified I
believe, but it looks like the loader was pulled out into it's own spec
https://github.com/rwaldron/tc39-notes/blob/b1af70ec299e996a9f1e2e34746269fbbb835d7e/es6/2014-09/sept-25.md#loader-pipeline,
not sure where that ended up
```js
var moduleName = 'foo';
var foo = require(moduleName);
```
would not work in browserify either
On Fri, Sep 26, 2014 at 12:40 PM, Konstantin Ikonnikov ikokos...@gmail.com
wrote:
I don't want load module using http request. In my case module already
defined and I want import it later when
(moduleName);
```
would not work in browserify either
It does work in browserify, but you need to be sure to include it in a
list of requires if it is not imported by the current list of files
statically (ala `browserify -e main.js -r foo`).
On Fri, Sep 26, 2014 at 12:21 PM, Calvin Metcalf
Would the System object for a module loaded with a sub classed System be
the sub classed one or the original one?
IMO a better design would have each platform subclass Loader, eg
SystemLoader extends Loader and System (or 'system' if we decide to
suddenly come to our senses) would be an instance
I wonder if this is related to normalize not having access to the metadata
http://jsbin.com/pazovohi/1/
On Wed, Jul 30, 2014 at 12:21 PM, John Barton johnjbar...@google.com
wrote:
The spec seems inconsistent about the metadata property. The define()
function of Loader accepts
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down to if a
CJS module imports an ES6 module that has a key named default, what should
the default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma off...@gmail.com wrote:
It's using
then complexity,
confusion and not serving their intended goals.
On Mon, Jul 21, 2014 at 3:18 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down to if
a CJS
module imports an ES6 module that has
export like module.exports.
On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma off...@gmail.com wrote:
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
that won't help if module.exports is a function
That's exactly what `minimist` is, works just fine.
https
, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so
currently
it so use a default export
```js
//cj2es6.js
imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method
named
helper or, more likely
It is implimented in bluebird
https://github.com/petkaantonov/bluebird/blob/master/API.md#any---promise
On Thu, Jul 17, 2014 at 12:53 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
I would think that proposed additions to the Promise spec ought to be
prototyped in something like `prfun` or
side channel which would likely break static checking of those
dependencies.
On Tue, Jun 24, 2014 at 2:16 PM, Juan Ignacio Dopazo jdop...@yahoo-inc.com
wrote:
On Tuesday, June 24, 2014 11:38 AM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
Say you wanted to add a hook which
circular dependencies in CJS are much easer then that
https://gist.github.com/calvinmetcalf/57be20b8eda0ee8fe6de
On Wed, Jul 2, 2014 at 4:09 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
On Tue, Jul 1, 2014 at 10:28 PM, Kevin Smith zenpars...@gmail.com wrote:
As such, we are
You can of course assume that the require call with a static string does
what you'd expect but then you might end up loading something that was
never actually required but someone had their own require function there
instead that has something else.
This is a solved problem actually
one benefit of default exports is forcing people to choose one of
export { x as exports };
export { x as default };
export { x as _ };
this is the one chance to get everyone on the same page
as far as object-as-module having circular dependency issues, can you
elaborate on that, I
Another interoperability issue is circular dependencies, es6 modules have
support for certain kinds that cjs doesn't (like function declarations)
and cjs has support for 2 modules using each others exports (as long as
they arn't single exports).
If it wasn't for this you could load cjs modules
I wrote up a gist summarizing the different proposals that were being
tossed around, it mainly says the same things as Andreas, just not as well
https://gist.github.com/calvinmetcalf/5d9a88abaa9fe094e960\
On Fri, Jun 27, 2014 at 10:02 AM, Kevin Smith zenpars...@gmail.com wrote:
+1
Yeah -
the slight difference in `import { MyClass } from my-class.js;` compared
to `var MyClass = require(./my-class.js);` is that in cjs MyClass is a
variable the user create, meaning the user only need to know about 1 name
from the remote module, the path, but in ES6 MyClass is set by the exporter
The place where the current syntax shines is when dealing with anonymous
values,
On Jun 25, 2014 1:29 AM, Barronville, Jonathan jonat...@belairlabs.com
wrote:
Kevin, you're not alone :) . I like that last form, too.
- Jonathan
—
Sent from Mailbox https://www.dropbox.com/mailbox
On Wed,
Thanks Kevin.
Back to bikeshedding import export syntax.
The refactoring hazards of defaulting to an object with all the exports are
going to depend on how the feature is described, talking in terms of
looking first for a default export and then returning the module body and
now you get
The
import 'foo'
let foo = this.get('foo')
Is less of a hassle if you only need it for when you have default and named
exports and need the module object.
On Jun 25, 2014 7:48 AM, Kevin Smith zenpars...@gmail.com wrote:
But if modules were said to have a default default export that
import 'foo'
let foo = this.get('foo')
that was what came out of the last meeting to replace module/from semantics
the payoff is decoupling how something is imported from how something is
exported. A module is a bag of names, but there is no reason an import has
to be as well.
On
default-default is the least worst one I have heard that doesn't totally
change everything,
On Wed, Jun 25, 2014 at 2:08 PM, Kevin Smith zenpars...@gmail.com wrote:
One import syntax. C'mon, we've been over this for *months* Kevin.
I get that, I really do. But specifically, that would
I've been doing work with the loader hooks and one gap that stands out is
that there is no hook to let you manipulate the exports and imports of an
module without parsing it yourself, in other words if you want to add,
remove, or modify exports or imports of a module you have to write your own
Bedford can provide more details on how he implemented this process in
es6-module-loader.
/caridy
On Jun 24, 2014, at 10:17 AM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
I've been doing work with the loader hooks and one gap that stands out
is that there is no hook to let you
to consume bar-shim instead of bar.
The same principle applies for alias, buckets, etc.
/caridy
On Jun 24, 2014, at 10:36 AM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
Say you wanted to add a hook which automatically added an export named
filepath to a module is the path to the file, or add
Side note: is that legal? I assumed you wouldn't be able to do that due to
default being a reserved word.
On Jun 24, 2014 7:53 PM, Kevin Smith zenpars...@gmail.com wrote:
I don't agree that the changes to the semantics are large, if we're
talking about simply allowing a single syntactic form
One other option could be for import name from 'path' to resolve to the
module body there is no default export, thanks to the static analysis
you'll always know when default is present.
The import 'path'/this.get syntax is a lot less burdensome if it's only
required by edge cases like needing
let bar = function () {}
```
and
```js
class Baz {
foo(){}
bar(){}
}
let baz = new Baz();
export default baz;
```
could both be imported the same.
On Thu, Jun 19, 2014 at 9:57 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf
They curly braces only look like destructuring if you keep the name the
same, when imported with a different name it's a slightly different syntax,
{oldname as newname} not {oldname: newname}, also as it currently stands
// BAD
import lib from 'library';
lib.foo();
lib.bar();
is
e.g. something like
https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7
On Mon, Jun 16, 2014 at 1:01 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
They curly braces only look like destructuring if you
:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7
re:
let { foo, bar } = import library;
Ignoring the UnaryExpression ambiguity, what happens here:
// library.js
export const MAX_VALUE = 1023
Jasper: none of those things are legal in the current spec
On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
isn't the foot gun the difference between single and multiple exports, i.e.
to import underscore you'd use
module _ from 'underscore'
because it is multiple methods on an object but for jquery you'd have to use
import $ from 'jquery'
because the root object is a function instead of an
, Jun 12, 2014 at 10:07 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
isn't the foot gun the difference between single and multiple exports,
i.e.
I thought it was imports that were being misused. People were writing
module m from 'mymodule';
m();
So they treated `module` just like
Many of the Set specific methods would also be useful if they worked on the
keys of Maps.
On Jun 7, 2014 3:44 PM, Hemanth H.M hemanth...@gmail.com wrote:
Yup, a generic collection API.
On Jun 7, 2014 7:10 PM, Calvin Metcalf calvin.metc...@gmail.com wrote:
If you would like to help write
If you would like to help write a library for them
https://github.com/calvinmetcalf/set.up
Another idea would be a generic collections API for maps, sets, arrays, and
other types of collections down the line like queues, trees, tries, etc
On Jun 7, 2014 3:13 PM, Barronville, Jonathan
```
var sources = [internal, external1, external2];
function doStuff (e) {
// likely check if it's the right kind of error;
var url = sources.shift();
if (typeof url === 'undefined) {
return Promise.reject(new Error('out of sources'));
}
return
if import statements could function as AssignmentExpression, they would be
a lot more useful, something like
```js
var foo = import 'ModuleSpecifier';
someFunc(import('somethingElse'));
```
It could still be statically linked regardless of whether the code was run,
but instead of creating a
Yes
On Jan 31, 2014 4:30 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Just to be clear: this is for an ask such that
```js
var foo = Math.random() 0.5 ? import 'bar' : import 'baz';
```
loads both `'bar'` and a`'baz'` every time.
, Jan 31, 2014 at 4:52 PM, Brendan Eich bren...@mozilla.com wrote:
Calvin Metcalf wrote:
Yes
The smell of expressions which evaluate depending on control flow not
matching both branches preloading is enough that TC39 defers this and
sticks to the ES6 grammar as proposed. We need to see enough
sorry guys, was getting confused on VariableStatement vs
AssignmentExpression, gist is updated with correct examples, I guess it
seems somewhat overly complicated having 4 different ways to export things
each with their own arbitrary restrictions which leads to weirdness, e.g.
if you want to
forgot to hit replay all
On Thu, Jan 30, 2014 at 10:25 AM, Kevin Smith zenpars...@gmail.com wrote:
[Did you mean to reply all?]
```js
var projs = [
import ./projections/merc,
import ./projections/longlat
];
```
That idea was last discussed on the list two or three years ago.
related, is it possible to export anonymous objects?
from looking at the spec it would seem that
```js
let foo = 1;
export foo as default;
```
would be allowed but
```js
export 1 as default;
```
would not
so to export an object that doesn't already have a name you'd have to
something like:
So the following are equivalent?
```js
export default foo();
export let default = foo();
```
On Jan 29, 2014 5:19 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Wed, Jan 29, 2014 at 2:00 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
`export default 1` works.
.
--
*From:* es-discuss es-discuss-boun...@mozilla.org on behalf of Calvin
Metcalf calvin.metc...@gmail.com
*Sent:* Wednesday, January 29, 2014 18:25
*To:* Jason Orendorff
*Cc:* EcmaScript; Erik Arvidsson
*Subject:* Re: restrictions on module import export names
So the following
, Jan 29, 2014 at 3:39 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
*would be equivalent of it was allowed
[...]
So the following are equivalent?
```js
export default foo();
export let default = foo();
```
Yes.
-j
--
-Calvin W. Metcalf
specific to set (as opposed to ones that work with array) would be the
mathematical set operations like union, symmetrical difference (think xor),
compliment, and intersection.
On Fri, Jan 3, 2014 at 12:52 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Dec 31, 2013 at 11:36 AM, David
I had the same idea a couple weeks ago and turned it into a library
https://github.com/calvinmetcalf/set.up if anyone finds it useful.
It adds all the array methods that make sense, ie reduce but not reduceRight
On Tue, Dec 31, 2013 at 2:36 PM, David Bruant bruan...@gmail.com wrote:
Hi,
58 matches
Mail list logo