Re: Forwarding `return()` in generators
Brendan Eich wrote: Axel Rauschmayer wrote: It’d be great if all iterables were indeed the same in this regard. I didn't reply to this last sentence. I don't agree that all iterables (we don't control the universe of such things, so perhaps you mean all standardized or built-in iterables) vend iterators with return methods. It's rare to both break from a for-of loop and want to iterate more after, so you're in hard-cases-make-bad-law land right there. Iterators are best used by getting fresh ones and consuming them till done (whether exhausted or not). `return` is required only if an iterator hangs onto a scarce-enough resource. Many (most?) iterators do not. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: short-circuiting Array.prototype.reduce
On Thu, Mar 26, 2015 at 8:22 PM, Kyle Simpson get...@gmail.com wrote:
outer = outer.filter(function filterer(inner){
return inner.reduce(function reducer(prev,current){
if (prev === false || prev === current) return false;
return current;
});
});
I think you could write that like this:
outer = outer.filter(arr =
!arr.some((e, i) =
i 0 arr[i-1] === e));
Array.prototype.some is designed to produce a boolean result and
already has early exit built in.
-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: short-circuiting Array.prototype.reduce
I think you could write that like this: outer = outer.filter(arr = !arr.some((e, i) = i 0 arr[i-1] === e)); Yes, you are of course correct. What I was doing in the originally cited code was illustrating using how `reduce(..)` by its nature supports the adjacency check, instead of using indexes and manual `i-1` type logic. IOW, I initially wanted to avoid the ugly `i-1`, and I traded that for the unfortunate lack of early exit necessitating the equally ugly `prev === false`. :/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Cancellation architectural observations
following up from this
https://github.com/whatwg/fetch/issues/27#issuecomment-86987752 , and most
likely late to the party.
How about cancel-ability done this way ?
```js
var p = new Promise(function (res, rej, cancel) {
// resolved in 1 second via random value
var t = setTimeout(res, 1000, Math.random());
// if meant to be canceled
// we define internally what to do
cancel(function () {
clearTimeout(t);
});
});
// whenever/if needed
p.cancel().then(...);
```
The exposed cancel-ability is arbitrary provided internally so that if
missing, an error is thrown while if provided it sets the internal state of
the promise as `canceled` in case it's different from `resolved` or
`rejected`
It gives the ability to react, if a `then` is attached, or the ability to
ignore, if nothing happens to the returned, non cancel-able, Promise.
This avoids exposing to the outer world what happens inside the Promise and
provides arbitrary ability to cancel one.
A cancel-able Promise is one that defined such behavior, which by default
is throwing if that's not defined internally.
This would solve already many cases I have in mind, via users, or
UserAgent, and legitimately behind the scene without any need to expose any
internal logic.
How to resolve or throw other attached promises? Well, `p.cancel().then()`
resolves, while `p.cancel().throw()` does not. `p.cancel()`, without then
or throw would simply throw away pending promises as explicit `ignore`
intent.
How bad does it look and what am I screwing up in here in terms of Promises
philosophy?
Best Regards
On Wed, Mar 4, 2015 at 8:01 PM, Ron Buckton ron.buck...@microsoft.com
wrote:
new Promise(resolve = doLater(resolve, cts.token)).then(handleResult);
setImmediate(() = cts.cancel());
In this scenario cancel would be called right after the resolve method
is called, but before handlerResult is called. For this to work with a
cancellation token you would need to pass 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?
I can be convinced that CancellationToken registrations should be invoked
asynchronously, though I wonder if then CancellationTokenSource#cancel
should return a Promise to observe any errors that occur.
Ron
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Within a generator body Arrow function formals treat yield as keyword but function declarations and expressions do not
Is this intentional?
14.1 Function Definitions
---
FunctionDeclaration[Yield, Default] :
function BindingIdentifier[?Yield] ( FormalParameters ) { FunctionBody }
[+Default] function ( FormalParameters ) { FunctionBody }
FunctionExpression :
function BindingIdentifieropt ( FormalParameters ) { FunctionBody }
---
14.2 Arrow Function Definitions
---
When the production
ArrowParameters[Yield] :
CoverParenthesizedExpressionAndArrowParameterList[?Yield]
is recognized the following grammar is used to refine the interpretation of
CoverParenthesizedExpressionAndArrowParameterList:
ArrowFormalParameters[Yield, GeneratorParameter] :
( StrictFormalParameters[?Yield, ?GeneratorParameter] )
---
Following the production rules for StrictFormalParameters and FormalParameters
you can end up at SingleNameBinding
SingleNameBinding[Yield, GeneratorParameter] :
[+GeneratorParameter] BindingIdentifier[Yield] Initializer[In]opt
[~GeneratorParameter] BindingIdentifier[?Yield] Initializer[In, ?Yield]opt
This looks like it suggests following:
var yield;
function* gf() {
function f(yield = yield) { } // valid parse, both yields are identifiers,
second binds to the global var
var f = function (yield = yield) { }; // same deal
var a = (yield = yield) = { }; // first yield is treated as keyword,
doesn't parse, second is treated as identifier and again binds to the global var
}
Binding to the global var in the default argument expressions is weird and
perhaps confusing but acceptable I suppose.
The inconsistency of the formal name treatment between functions and arrow
functions feels wrong to me given that the formal names are created in
non-generator scopes.
Ian
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
