This is something I stumbled across while looking into the for-of-with (aka
continue-with/break-with). It seems like throwing inside a for-of loop does
not call the iterators throw method, it calls the return method and it
seems to disregard the result of the method. For eample:
```js
var gen = ()
.com
>
>
> On Tue, Aug 22, 2017 at 12:30 PM, Isiah Meadows
> wrote:
> > Inline:
> >
> >
> > On Tue, Aug 22, 2017 at 3:36 AM, Marius Gundersen
> wrote:
> >> One of the reasons I think for-of should handle this is because of the
> error
&
One of the reasons I think for-of should handle this is because of the
error handling. [Closing an iterator](
http://raganwald.com/2017/07/22/closing-iterables-is-a-leaky-abstraction.html)
is not trivial, and so having to write that code yourself is error prone.
I originally considered `continue x
e or more variables outside the scope of the
>> generator function during iteration, which the generator function can read.
>> Is this so bad?
>>
>> On Mon, 21 Aug 2017 at 15:24 Marius Gundersen
>> wrote:
>>
>>> Generators today can both "send"
true;
_iteratorError = err;
} finally {
try {
if (!_iteratorNormalCompletion && _iterator.return) {
_iterator.return();
}
} finally {
if (_didIteratorError) {
throw _iteratorError;
}
}
}
```
Marius Gundersen
__
useful if it could take the name of the
flatmap argument (mapFunc).
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
wait sauce);
(await dough).add(await cheese);
return (await dough);
}
Now the variables will be awaited on first use
Marius Gundersen
On 24 Feb 2017 03:36, "Šime Vidas" wrote:
Daniel Brain from PayPal has written a post about async/await:
https://medium.com/@bluepnume/even-
Would it not be better to expose the names (and default values,
destructurings, etc) of the function arguments using reflection? For
example, Reflection.arguments(Math.max).then this method can return any
JSDoc it is able to parse.
On 16 Apr 2016 16:53, "Caitlin Potter" wrote:
> How would that in
Do we really need to add support for await in a pipeline syntax sugar when
there already is a piping support in `.then()`? If you need to await
something in that chain, then just use `.then()`.
```js
let result = await fs.readFile('index.txt')
.then(aSingleParamFunction)
.then(anotherSinglePar
from "iterator-math";
[1,2,3,4]::sum(); //10
[1,2,3,4]::mean(); //2.5
[{a:1}, {a:2}, {a:3}, {a:4}].map(x => x.a)::sum(); //10
```
[1] https://github.com/zenparsing/es-function-bind
Marius Gundersen
On Mon, Oct 5, 2015 at 3:54 PM, Eli Perelman wrote:
> We aren't really arguin
One advantage of #4 is that it will make it possible to introduce either #2
or #3 in the future, if we change our minds. This way we can use real world
use cases to decide if we should go for #2 or #3.
Marius Gundersen
On Fri, Sep 25, 2015 at 1:23 AM, Waldemar Horwat
wrote:
> My preference
let
> var foo=...;`.
>
>
let and mut? Oh well, too late for that now.
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ss the token to every step in the
chain to both stop work being done and to ignore the result/prevent a
handler from being called. Wouldn't it be better if the promise chain took
care of this for the programmer?
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ove callback is never run
p2.ignore();
```
Maybe calling ignore on a rejected or resolved promise should throw.
Marius Gundersen
On Mon, Mar 2, 2015 at 8:59 AM, Salvador de la Puente González <
sa...@unoyunodiez.com> wrote:
> I think this did not reach the mailing list to the W3:
&
) {}
>>> NullBase.prototype = Object.create(null);
>>>
>>> class C extends NullBase {}
>>>
Can't this be solved by returning a null object from the constructor?
```js
class Null{
constructor() {
return Object.create(null);
}
}
class
reason for
the exception to travel up the stack. Either the exception must be handled
as a rejected promise or it must be handled in something like
`window.onerror`.
Marius Gundersen
On Tue, Jan 13, 2015 at 12:35 PM, Boopathi Rajaa
wrote:
> ```
> Promise
> .resolve()
> .then(functi
derstand and not ambiguous for machines is to wrap or prefix
the block, but not the object, for example with do:
x => do {
let a = 5;
return a*x;
}
AFAIK do expressions are not in ES6, but might be in ES7.
Marius Gundersen
On 6 Jan 2015 19:42, "Brendan Eich" wrote:
> Sorry,
One scenario where arrow functions are likely to return objects is in the
map function of arrays and the pipe function for streams. For example:
[1,2,3]
.map(x => {value: x, double:2*x})
.filter(x => x.double < 5)
Marius Gundersen
On 5 Jan 2015 21:16, "Kevin Smith" wrote:
&
doesn't fat-arrow solve this? It's not that verbose, and you can put the
arguments in any order you want
```js
[1,2,3].forEach(element => myCallback("something else", element));
```
Marius Gundersen
___
es-discuss mailing list
So are all of these legal?
```js
var a = 1;
export a;
var b = 1;
export default b;
export var c = 1;
export var d = 1, e = 2, f = 3;
```
What about:
```js
var default = 1;
export default;
var b = 1;
export default b;
```
Sorry for not being very good at reading EBNF
Marius Gundersen
On Mon
to guess through message parsing otherwise
> ;-)
>
>
As always I believe the properties should be machine readable and therefore
be exposed on the Error object instead of having to parse the message.
Marius Gundersen
___
es-discuss mailing
ing similar) sounds like a good solution to me.
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
it should be
possible for one window to handle the errors in child windows (taking same
origin and CSP into consideration ofcourse). This should probably be
generalized to realms, so that one realm can catch all the errors in
another realm.
Marius Gundersen
___
ne number/character
number is not yet available.
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
):
```js
var moduleName = 'foo';
Loader.import(moduleName).then(function(foo){
//use foo here
});
```
Marius Gundersen
On Fri, Sep 26, 2014 at 5:29 PM, John Barton wrote:
> no.
>
> On Fri, Sep 26, 2014 at 8:12 AM, Konstantin Ikonnikov > wrote:
>
>> Can I
array is the values to be inserted. That
would let you do:
```js
var query = sql(...String.noIndent`
select * from myDB
where username='${user}'
and password='${password}'
`);
```
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
nd the entire
dependency graph as a JSON file to the client (for example using bloom
filters and a slightly smarter server), and I'm sure the community will
find the best pre-fetching strategy with the tools already available to
them.
Marius Gundersen
[1]: https://developer.mozilla.org/en-US/d
On Wed, Aug 6, 2014 at 2:10 PM, Kevin Smith wrote:
>
>> Completely agree, the default should be removed. This is simply a
>> proposal of how we can still have a simple import statement (`import $ from
>> "jQuery";`) without needing `default`.
>>
>>
> You know, I hate even suggesting any syntax ch
On Wed, Aug 6, 2014 at 1:04 PM, Kevin Smith wrote:
>
>> It would be great if we could have single export modules without using
>> the `default` keyword to mark the exported binding as being special. One
>> way to do this is for method A (import without curly braces) to import the
>> first exporte
On Wed, Aug 6, 2014 at 1:02 PM, Kevin Smith wrote:
>
>> * The name of the imported binding is decided by the user of the module,
>> not the author
>> * The user of the module does not need to know the name of the exported
>> binding, set by the author of the module.
>>
>
> If you seriously want
ject (which is available using `module
theModuleObject from "moduleThatExportsSeveralBindings"`) is iterable, so
the first entry can be accessed.
I therefore want to propose that the default keyword is removed, that only
named bindings are allowed when exporting in a module, and that method A
r to use than a named export.
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
dy has proposed it
yet.
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I propose the tau constant be added to the Math object and be defined as
2*Math.PI, as described in the tau manifesto:
http://tauday.com/tau-manifesto
(I couldn't find any discussion about this when searching esdiscuss.org, so
sorry if this has been discussed before)
Marius Gund
t to the default export. If the
default export is an object with properties (or a function with properties,
which I quite common in npm) then there is no static checking of those
properties. So with today's spec there is one way to get static checking
and one ways (default) to not get sta
lection of exports (the bag) and named values from the bag:
```js
import _, {map, reduce, filter} from "underscore";
assert(_.fiilter === filter);
```
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
to the module. The only downside to this is the
(apparently mandatory) curly braces around the imported object. If single
export/import becomes the convention with ES6 modules then users will be
forced to type an extra pair of {} several times in most of their fil
is syntax could work
without deviating very far from the current spec. It seems easier to get
the spec to favor multiple export (which, to me, it looks like it was
originally designed to favor). I don't have any preference either way, I
just want it to favor one, both on the export and import
On Tue, Jun 10, 2014 at 9:06 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Marius Gundersen
>
> > This will likely lead to a lot of confusion, not only for module makers
> but a
t the two exports are the same object
(which for underscore will likely lead to bugs):
```js
export default = 5;
export {1 as a};
//in another module
import {a} from "sillyModule";//a is 1
import a from "sillyModule"; //a is 5
```
This will likely lead to a lot of confu
What is an arrow function bound to in a module?
```js
export var a = () => this;
```
On Mon, Jun 9, 2014 at 7:08 PM, Caridy Patino wrote:
> My point: if 'this' is not global in modules, then ES6 must have an
>> alternative way to name the global object.
>>
>
> Yes, we covered that last week. `
On Mon, Jun 9, 2014 at 7:40 PM, Karolis Narkevičius
wrote:
> Why can't we have both with the same syntax?
>
> ```js
> // imports a function which is the default export
> import mkdirp from "mkdirp";
> ```
>
> and
>
> ```js
> // imports all named exports, like module used to
> import fs from "fs";
created. This would
unfortunately add an extra step in passing uvalues between realms, but it
might just be a minor inconvenience.
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Jan 28, 2014 at 2:13 AM, James Burke wrote:
> On Mon, Jan 27, 2014 at 3:14 PM, John Barton
> wrote:
> > On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt <
> sa...@cs.indiana.edu>
> > wrote:
> >> Imagine that some browser has an ok-but-not-complete implementation of
> >> the X library
ould probably
be thrown, or the promise could be rejected. But I don't think that would
be good for DOM manipulation. If innerHTML is used to add a lot of markup
and an existing module to the DOM, should an error be thrown? Should none
of the other markup be added to the DOM? What would the er
On Mon, Jan 27, 2014 at 11:08 PM, Jason Orendorff wrote:
> On Mon, Jan 27, 2014 at 1:54 PM, Marius Gundersen
> wrote:
> > I didn't find anything in the spec on handling multiple modules with the
> > same name [...]
> > What should happen in such a scenari
the DOM?
Should it be a no-op, with no feedback to the user?
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
b;
var async = (a, b) ~> (await a) + (await b);
Marius Gundersen
On Thu, Dec 12, 2013 at 11:49 AM, Forbes Lindesay wrote:
> I always want the * to be mandatory for full generator functions as a
> visual cue. I suspect I would want something similar for async functions
> but I can
On Nov 8, 2013 1:46 AM, "Mark Miller" wrote:
>
> On Thu, Nov 7, 2013 at 4:27 PM, Marius Gundersen
wrote:
>>
>> It seems that every (real) usecase for weakRefs, weakMaps and weakSets
is to implement a weak event listener system.
>
>
> Not true. Even silly.
dispatcher has a
hidden iterable weakSet of listeners. It iterates over this weakSet and
notifys each entry of the event which has occured. But it does not expose
this iterable set.
Does it sound like weak event listeners could solve the challenges you
face? Is there a problem which can be i
eak myBlock;
myGlobal = 10;
}
console.log(myGlobal); //50% of the times it will be 5, 50% of the times it
will be 10.
```
This all works today (except for the let declaration), so not sure if
anything is needed to replace this.
Marius Gundersen
On Mon, Nov 4, 2013 at 12:36 PM, Axel Rauschmayer wr
any
native dom event handlers, so your trick with the eventHandler method won't
work. And we use pubsub, which affect observables on the `this` object, and
Ajax is handled through Promises, which also needs access to the `this`
object.
Marius Gundersen
On Oct 2, 2013 11:35 PM, "Andre
a single line, it takes care of the this variable,
which is used in a lot more places than DOM event handlers.
Marius Gundersen
On Wed, Oct 2, 2013 at 8:14 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> If you cannot use fat arrow to define prototypes than you cannot recycle
>
something which stores the truthyness of obj in a register, until the
expression is completely evaluated?
Thanks for the detailed information you can provide on this subject btw.
Marius Gundersen
Den 8. sep. 2013 21:43 skrev "Brendan Eich" følgende:
> Did you read my reply o
So how about implementing toBoolean as an overridable method, which is
called whenever !, || or && are used. This way an objec has three method
for converting it into a primitive; toString, toValue and toBoolean.
Marius Gundersen
On Sun, Sep 8, 2013 at 2:19 AM, Till Schneidereit wrot
> That's the way ToBoolean has always been defined
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-7.1.2 . All
objects are considered to be Boolean true values.
So does this mean I can override toBoolean to change the way ! behaves on
an object?
Marius G
he same way as
the other operators?
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ES6 or the array in AMD):
https://gist.github.com/mariusGundersen/5884450
Marius Gundersen
On Thu, Jun 27, 2013 at 8:27 PM, Brandon Benvie wrote:
> On 6/27/2013 3:19 AM, Marius Gundersen wrote:
>
>> Or maybe it just isn't implemented in Firefox?
>>
>
&
/Exception: missing ) after formal parameters (line 1)
I haven't found this defined in the current grammar, but would be useful
for something I'm currently working on. Or maybe it just isn't implemented
in Firefox?
Marius Gundersen
___
e
else has weak references and so the widget (and all its
children) are garbage collected and stop listening to events when the
parent deletes it.
Hopefully this is enough of a usecase to make WeakRefs (or one of the
alternatives, for example, an iterable set of weak references to
functions/obje
em if the only allowed argument to a
weak reference is a function. An iterable weak set of functions would not
have this problem, would solve the suggested usecases for weak references
(observables/events):
Marius Gundersen
On Mon, Apr 1, 2013 at 10:39 PM, Brendan Eich wrote:
> Marius Gundersen w
this seems
less like a problem with weak references, and more like a problem with
specific implementations of GCs.
Marius Gundersen
On Fri, Mar 29, 2013 at 3:47 AM, Oliver Hunt wrote:
>
> On Mar 29, 2013, at 7:36 AM, David Herman wrote:
>
> > On Mar 27, 2013, at 4:52 AM, Sam Tobi
x27;m not sure of how big of a
problem this would be; it might be an annoyance or it might break the
application completely.
Marius Gundersen
On Tue, Mar 26, 2013 at 4:24 AM, Benoit Marchant wrote:
> Very true, I'm wondering if based on usage today it could make sense to
> have
ple the event system does not hold a strong reference to the
listener/handler function, so if nothing else has a reference to the
handler function, it is garbage collected.
Any thoughts on this, as an alternative to the more general (and low level)
weak references?
Marius Gundersen
__
than (not) calling the addEventListener
every time.
The explicit reattaching of the rAF works because you know how long it is
until the next animation frame, but it won't work in a system where the
time until the next event is indeterminable.
Marius Gundersen
___
> I won't say it's absolutely better than WeakRefs and it may not apply to
the data binding case (?), but it's an interesting pattern to keep in mind.
I can't see how this would work in an observer/listener application. The
listening object has no way of knowing if it will be deleted when the even
ing as FP is a bit of a trend today (due, in part, to the
popularity of JavaScript), it seems to me like a good idea to implementing
features which help promote good FP patterns in a language that allows for
both FP and OOP.
David
>
> Le 28/11/2012 12:50, Marius Gundersen a écrit :
>
On Wed, Nov 28, 2012 at 1:20 PM, Andreas Rossberg wrote:
> On 28 November 2012 12:50, Marius Gundersen wrote:
> > Has there been any work done on pure functions in EcmaScript? The way I
> > imagine it, there would be a way to indicate that a function should be
> pure
> >
on@(a, b){
return a+b;
}
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ry (and many other frameworks) do a lot of things with |this| behind
the scenes, where it would be very nice to have |this| be set by the
framework.
Or is the consensus that the current way of doing this is not good, and
should be discurraged?
Marius Gundersen
nces of objects/arrays?
For example:
var obj = {};
obj.b = {};
obj.a = obj.b;
Would produce:
{
"b": {},
"a": path(/b)
}
and could be parsed so adding a member to either obj.b or ob.a would update
the other one. This would therefore be more powerfull than simply cop
avaScript object, and no way to
recontstruct a JavaScript object from this json string. Therefore paths
should only be able to refer to objects or arrays.
Marius Gundersen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
72 matches
Mail list logo
