Re: Determine if a value is Callable/Constructible

> There is no intrinsic reason why we needed to mandate that class constructors > should throw when called. We even provided a simple and straight forward way > (new.target===undefined) that a ES constructor body can use to determine > whether it was called or new’ed. > > I think we should jus

Re: `of` operator ES7 proposal from Ian Bicking

First possible problem - "of" used in if statement can put iterator in unexpected state or result in arbitrary side effects. Of course, code like "piece.isKing()" can have side effects too, but any programmer comming from any language is conscious of this danger. Using operator obsfucates this. On

Re: Determine if a value is Callable/Constructible

It doesn’t seem that big of a deal, but one risk is: people mistaking a class for a constructor, trying to subclass it as if it were a constructor and things failing silently. > On 30 Mar 2015, at 07:49, Allen Wirfs-Brock wrote: > > >> On Mar 29, 2015, at 11:51 PM, Caitlin Potter wrote: >>

Re: `of` operator ES7 proposal from Ian Bicking

* Name-wise, is `has` a possibility? It feels more intuitive and I don’t think the duality with `in` matters (given that `for-in` will probably rarely be used in the future, due to `for-of` and `Map`). * Will it ever be possible to define arbitrary infix operators? If yes, should this operator

Re: Determine if a value is Callable/Constructible

On Sun, Mar 29, 2015 at 10:49 PM, Allen Wirfs-Brock wrote: > > > On Mar 29, 2015, at 11:51 PM, Caitlin Potter > wrote: > > > > ... > > > > Reflect.isConstructor(fn) -> true if Class constructor, generator, or > legacy (and non-builtin) function syntactic form > > Reflect.isCallable(fn) -> true f

Re: Determine if a value is Callable/Constructible

> On Mar 29, 2015, at 11:51 PM, Caitlin Potter wrote: > > ... > > Reflect.isConstructor(fn) -> true if Class constructor, generator, or legacy > (and non-builtin) function syntactic form > Reflect.isCallable(fn) -> true for pretty much any function, except for class > constructors and a few b

`of` operator ES7 proposal from Ian Bicking

From https://plus.google.com/+IanBicking/posts/PbXDtNF9Gg6: """ Ian Bicking Shared publicly - Mar 24, 2015 #Array Huh, "for (attr in obj)" goes along with "if (attr in obj)", but "for (item of array)" doesn't have an equivalent "if (item of array)" There is a proposal I guess for a method, bu

Re: Determine if a value is Callable/Constructible

Caitlin Potter wrote: Well just to get the ball rolling, I’ve put together a markdown doc for this https://github.com/caitp/TC39-Proposals/blob/master/tc39-reflect-isconstructor-iscallable.md It’s such a minor item that I’m not sure how much to add to it, so maybe someone else will have a g

Re: Determine if a value is Callable/Constructible

Well just to get the ball rolling, I’ve put together a markdown doc for this https://github.com/caitp/TC39-Proposals/blob/master/tc39-reflect-isconstructor-iscallable.md It’s such a minor item that I’

Re: Determine if a value is Callable/Constructible

Last thread: https://esdiscuss.org/topic/add-reflect-isconstructor-and-reflect-iscallable. Died off again. There's no issue with ES7 vs. ES6 without a spec, and having a draft spec at the right stage (1 for flagged implementation?) is the thing. Who will do it? /be Caitlin Potter wrote: *

Re: Supporting feature tests directly

Without the direct feature test API I'm suggesting (or something like it), how will someone feature test the two new (proposed for ES7) `export` forms, for example? https://github.com/leebyron/ecmascript-more-export-from I'm not strongly opposed to going the `Reflect.parse(..)` route for featu

Re: Does async/await solve a real problem?

jordi baylina schrieb: I propose that all the calls to any async function will be implicit (without the need of the await keyword). And precede it with a nowait only when you want a promise. This way, the code will not have the async clutter in the logic of the function, but will be need to be

Re: Cancellation architectural observations

quickly at least one thought: `this` inside a Promise callback, is not the Promise itself so nothing could possibly work. Moreover, you are setting an event that does not cancel, it resolves. Meaning all attached Promised will resolve too which is IMO not what "cancel" mans in the dictionary. My

Determine if a value is Callable/Constructible

**disclaimer** I know this has been brought up before, but bump :> People are experimenting with polyfilled class implementations, which don’t all correctly throw when called as a function (no `new`). Eventually, they’re likely to be disappointed that this isn’t legal, and might have to undergo

Re: Cancellation architectural observations

I don't think this has been brought up, but isn't what we're doing here bubbling an event? Would it make sense to generalize this to a simple event bubbling system? function cancelableGet(url){ const xhr = new XMLHttpRequest(); return new Promise(function(resolve, reject){ xhr.open('get',

Re: Cancellation architectural observations

OK, just for record sake, I'v ecreated a working example of what I previously meant. https://gist.github.com/WebReflection/a015c9c02ff2482d327e Here a basic example (something that will reject on timeout) ```js // will be resolvednew Promise(function ($res, $rej, ifCanceled) { var internal = se

Re: The ES6 iteration protocol

Good write up, although "fresh vs singleton" topic doesn't make sense, and doesn't reflect the spec. I responded on the gist. Dmitry On Sat, Mar 28, 2015 at 4:41 AM, Axel Rauschmayer wrote: > FWIW: I have written down my understanding of the ES6 iteration protocol > (shaped by discussions I had