Re: Array.forEach() et al with additional parameters
Le 20/12/2014 13:47, Gary Guo a écrit :
bindParameter function is not very hard to implement:
```
Function.prototype.bindParameter=function(idx, val){
var func=this;
return function(){
var arg=Array.prototype.slice.call(arguments);
arg[idx]=val;
func.apply(this, arg);
}
}
```
It's even easier if you use bind ;-)
Function.prototype.bindParameter = function(...args){
return this.bind(undefined, ...args)
}
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Array.forEach() et al with additional parameters
On Mon, 22 Dec 2014 11:37:04 +0100, David Bruant bruan...@gmail.com
wrote:Function.prototype.bindParameter = function(...args){
return this.bind(undefined, ...args)
}
But this will bind all parameters. In Christian Mayer's situation, she wants
first three parameters unbound while your solution will not work. :-)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Will `for (var a of null) {}` throw an error?
On Mon, 22 Dec 2014 21:06:18 +0800, Glen Huang curvedm...@gmail.com
wrote:Ideally it shouldn’t, because its twin `for (var a in null) {}` won’t.
But looking at step 8 in
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation,
when passing `null` to `GetIterator()`, it will throw a type error when the
result of step 2 `CheckIterable(null)`, which is `undefind`, is called in step
3 in the algorithm for `GetIterator()`.
Did I miss something or the current spec does throw an error?
To me since `IsCallable(undefined)` is `false`, so it throws an `TypeError`.
Traceur and V8 will both throw a `TypeError` saying that cannot read property
@@iterator from undefined or null, and Firefox throws a `TypeError` saying that
null have no property. So it should be an error.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.forEach() et al with additional parameters
if you don't need a context, you can simply use it to pass anything you
want.
as example, instead of this
On Sat, Dec 20, 2014 at 12:12 PM, Christian Mayer m...@christianmayer.de
wrote:
[1,2,3].forEach( myCallback, undefined, 'additionalFoo' );
you could do this:
[1,2,3].forEach( callback, ['additionalFoo']);
and callback will look like
function callback( element, count, array )
{
myCallback.apply(nulll, element, count, array.concat(this));
}
In this way you can prepend, append, swap index, use just what you need ...
etc ... I don't think it can be simplified any better with yet another
change to the Array API
Best Regards
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.forEach() et al with additional parameters
forgot squared brckets ...
myCallback.apply(nulll, [element, count, array].concat(this));
On Mon, Dec 22, 2014 at 1:29 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
if you don't need a context, you can simply use it to pass anything you
want.
as example, instead of this
On Sat, Dec 20, 2014 at 12:12 PM, Christian Mayer m...@christianmayer.de
wrote:
[1,2,3].forEach( myCallback, undefined, 'additionalFoo' );
you could do this:
[1,2,3].forEach( callback, ['additionalFoo']);
and callback will look like
function callback( element, count, array )
{
myCallback.apply(nulll, element, count, array.concat(this));
}
In this way you can prepend, append, swap index, use just what you need
... etc ... I don't think it can be simplified any better with yet another
change to the Array API
Best Regards
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Will `for (var a of null) {}` throw an error?
In that case we have a gotcha.
Is there any interest to change that behavior? Since es6 isn’t finial yet.
On Dec 22, 2014, at 9:29 PM, Gary Guo nbdd0...@hotmail.com wrote:
On Mon, 22 Dec 2014 21:06:18 +0800, Glen Huang curvedm...@gmail.com wrote:
Ideally it shouldn’t, because its twin `for (var a in null) {}` won’t.
But looking at step 8 in
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation,
when passing `null` to `GetIterator()`, it will throw a type error when the
result of step 2 `CheckIterable(null)`, which is `undefind`, is called in
step 3 in the algorithm for `GetIterator()`.
Did I miss something or the current spec does throw an error?
To me since `IsCallable(undefined)` is `false`, so it throws an `TypeError`.
Traceur and V8 will both throw a `TypeError` saying that cannot read property
@@iterator from undefined or null, and Firefox throws a `TypeError` saying
that null have no property. So it should be an error.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Will `for (var a of null) {}` throw an error?
for in and for of do completely different things and there is no reason to
expect consistency between them.
This was discussed already; search esdiscuss.org.
On Dec 22, 2014 8:37 AM, Glen Huang curvedm...@gmail.com wrote:
In that case we have a gotcha.
Is there any interest to change that behavior? Since es6 isn’t finial yet.
On Dec 22, 2014, at 9:29 PM, Gary Guo
nbdd0...@hotmail.commailto:nbdd0...@hotmail.com wrote:
On Mon, 22 Dec 2014 21:06:18 +0800, Glen Huang
curvedm...@gmail.commailto:curvedm...@gmail.com wrote:
Ideally it shouldn’t, because its twin `for (var a in null) {}` won’t.
But looking at step 8 in
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation,
when passing `null` to `GetIterator()`, it will throw a type error when the
result of step 2 `CheckIterable(null)`, which is `undefind`, is called in step
3 in the algorithm for `GetIterator()`.
Did I miss something or the current spec does throw an error?
To me since `IsCallable(undefined)` is `false`, so it throws an `TypeError`.
Traceur and V8 will both throw a `TypeError` saying that cannot read property
@@iterator from undefined or null, and Firefox throws a `TypeError` saying that
null have no property. So it should be an error.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.forEach() et al with additional parameters
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will `for (var a of null) {}` throw an error?
Thanks. Found that discussion, and after thinking about it again, throwing
errors on null/undefined actually makes sense, because it’s impossible to
sliently loop over null/undefined with regular for loop (if you check length
directly) or forEach directly. So throwing an error is actually consistent with
how things work in es3/5.
On Dec 22, 2014, at 9:54 PM, Domenic Denicola d...@domenic.me wrote:
for in and for of do completely different things and there is no reason to
expect consistency between them.
This was discussed already; search esdiscuss.org.
On Dec 22, 2014 8:37 AM, Glen Huang curvedm...@gmail.com wrote:
In that case we have a gotcha.
Is there any interest to change that behavior? Since es6 isn’t finial yet.
On Dec 22, 2014, at 9:29 PM, Gary Guo nbdd0...@hotmail.com
mailto:nbdd0...@hotmail.com wrote:
On Mon, 22 Dec 2014 21:06:18 +0800, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
Ideally it shouldn’t, because its twin `for (var a in null) {}` won’t.
But looking at step 8 in
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofexpressionevaluation-abstract-operation,
when passing `null` to `GetIterator()`, it will throw a type error when the
result of step 2 `CheckIterable(null)`, which is `undefind`, is called in
step 3 in the algorithm for `GetIterator()`.
Did I miss something or the current spec does throw an error?
To me since `IsCallable(undefined)` is `false`, so it throws an `TypeError`.
Traceur and V8 will both throw a `TypeError` saying that cannot read property
@@iterator from undefined or null, and Firefox throws a `TypeError` saying
that null have no property. So it should be an error.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Any news about the `module` element?
From: Allen Wirfs-Brock al...@wirfs-brock.com To: Anne van Kesteren ann...@annevk.nl Cc: es-discuss list es-discuss@mozilla.org Date: Sun, 21 Dec 2014 14:45:08 -0800 Subject: Re: Any news about the `module` element? On Dec 21, 2014, at 10:10 AM, Anne van Kesteren wrote: On Sun, Dec 21, 2014 at 5:42 PM, James Burke jrbu...@gmail.com wrote: (I am sure you are aware of the coming Service Worker bliss, so not just a curious side issue): I and some others have been advocating for service workers to run in strict mode by default, as well as having this be undefined so they could later be upgraded to be module compatible without requiring some new out-of-band switch. It hasn't really gotten much traction unfortunately. Wait a minute. Strict mode is not a runtime mode it is a lexical characteristic of a JS source file (or the source code of a function). You can this take an arbitrary JS file an say its going to be run in strict mode. You could say that the source code for a Service Worker must be a Module (which implies that it is strict mode) even in import and export statements aren't yet support. But this would be a bit more work for implementations as it means that top-level module semantics (top level declarations are module local) would have to be implemented. Allen A far as I know, much of the scope handling, sans strict mode, has been implemented in Node for years, so I don't expect it would be too extraordinarily hard to implement (particularly so for V8/consumers in this case). I may be wrong, though. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Will `for (var a of null) {}` throw an error?
Actually I propose a change in texts in the specification. CheckIterable ( obj )1. If obj is `undefined` or `null`, then return `undefined`.2. If type(obj) is Object, then return Get(obj, @@iterator).3. Let box be ToObject(obj).4. ReturnIfAbrupt(box).5. Return the result of calling the [[Get]] internal method of box passing @@iterator and obj as the arguments. This is way more too complex. We know that there are three situation:1. obj is `undefined` or `null`2. obj is of a primitive type3. obj is an object In 1, we don't care if it returns undefined or throw a TypeError. In ES6 spec, there are two uses of the undefined returned. One of them passes it as F to Call, the other passes it to ToObject. Both of them will result in TypeError. So we can just let this step throw TypeError instead of return `undefined`. I suggest we can a little bit combine these steps: CheckIterable (obj)1. Let box be ToObject(obj).2. ReturnIfAbrupt(box).3. Return the result of calling the [[Get]] internal method of box passing @@iterator and obj as the arguments. If obj is `undefined` or `null`, the first step will fail and throw TypeError. If obj is primitive, it's boxed. If obj is an object, it is no-op in ToObject. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will `for (var a of null) {}` throw an error?
Your suggestion breaks Array.from and TypedArrayFrom. /be Gary Guo wrote: I suggest we can a little bit combine these steps: CheckIterable (obj) 1. Let box be ToObject(obj). 2. ReturnIfAbrupt(box). 3. Return the result of calling the [[Get]] internal method of box passing @@iterator and obj as the arguments. If obj is `undefined` or `null`, the first step will fail and throw TypeError. If obj is primitive, it's boxed. If obj is an object, it is no-op in ToObject. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Elegant way to generate string from tagged template?
When a template is passed to a function, what’s the quickest way to return a
string with additional arguments being interpolated into the template?
For example,
```
minify`
ul
li${content}/li
/ul
`
```
In this case`minify` will return the minified html, but what’s the quickest way
to get the unminified string interpolated from the template? What I can think
of is to loop over the additional arguments, and interspersedly join the
elements in template object with the arguments, and then append the dangling
element in template object. Sounds very tedious. Does es6 have an array method
to ease this transformation?
What such method does basically, should be the following:
Given an array of [1,2,3] and other array of [“a”,”b”], it should return
[1,”a”,2,“b”,3]. (probably a lot of edge cases to cover, but just ignore them
for now).
But maybe I overthink this? Is there already an easy way to do this?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Will `for (var a of null) {}` throw an error?
Date: Mon, 22 Dec 2014 21:28:54 -0800 From: bren...@mozilla.org Your suggestion breaks Array.from and TypedArrayFrom. In the spec: 8. Let arrayLike be ToObject(items). A type error will also be thrown since null and undefined are not ObjectCoercible.___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
