Re: Additional Set.prototype methods

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,

Re: Additional Set.prototype methods

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

Re: restrictions on module import export names

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:

Re: restrictions on module import export names

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.

RE: restrictions on module import export names

. -- *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

Re: restrictions on module import export names

, 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

Re: restrictions on module import export names

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

Re: restrictions on module import export names

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.

Import Expressions

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

RE: Import Expressions

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.

Re: Import Expressions

, 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

Re: Re: Promises, the middle state : negociation

``` 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

Re: Basic set operations?

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

Re: Basic set operations?

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

Re: Re: Rationale for dropping ModuleImport syntax?

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

Re: Re: Rationale for dropping ModuleImport syntax?

, 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

Re: ES6 modules (sorry...)

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

Re: ES6 modules (sorry...)

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

Re: ES6 modules (sorry...)

: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

Re: ES6 modules (sorry...)

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

Re: ModuleImport

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

Re: ModuleImport

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

Loader Hooks

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

Re: Loader Hooks

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

Re: Loader Hooks

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

Re: ModuleImport

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

Re: Module Default Export Syntax

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,

Re: ModuleImport

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

Re: ModuleImport

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

Re: ModuleImport

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

Re: ModuleImport

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

Re: Default exports, without explicit syntactic support

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

Re: ModuleImport

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 -

Re: ModuleImport

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

Re: ModuleImport

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

Re: Loader Hooks

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

Re: ModuleImport

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

Re: ModuleImport

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

Re: Promise.any

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

Re: Re: Quantifying Default Exports

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

Re: Re: Quantifying Default Exports

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

Re: Re: Quantifying Default Exports

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

Re: Re: Quantifying Default Exports

, 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

Re: Re: Quantifying Default Exports

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

Re: Loader locate/fetch/translate/instantiate API

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

Re: Loader vs ES6 Classes

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

Re: dynamic synchronous import

```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

Re: dynamic synchronous import

(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

Re: Importing modules that don't exist

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

Re: (x) = {foo: bar}

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

Re: Are ES6 modules in browsers going to get loaded level-by-level?

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

Re: Putting `global` reference in specs

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

Re: Is anyone able to reach wiki.ecmascript.org ?

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 >

Re: PRNG - currently available solutions aren't addressing many use cases

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 >

Re: New Set.prototype methods

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. > >

Re: es7-membrane: A new ECMAScript 2016 Membrane implementation

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.

Re: Microtask scheduling

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.

Re: Microtask scheduling

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