Sorry but still not exact, the use of Object.getOwnPropertyNames through
prototype chain can result in duplicate keys in override cases, so if we
implement this API ourself it could be quite complex (involving a Map to filter
duplicated keys)
I’m just wondering is there any reason that Reflect
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Gray Zhang
I’m just wondering is there any reason that Reflect API is not suitable to
provide such functionality?
Reflect currently contains only methods which correspond to proxy traps. There
has been talk of extending it
I'd rather migrate to a new standard than bring EventEmitter
If we can get an EventEmitter more suitable than the one node.js has to
offer, I am all for it.
On Mon, Jun 1, 2015 at 3:24 PM Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Dan Peddle wrote me without replying to all about
Dan Peddle wrote me without replying to all about the limit that is
configurable ... yes, I know that, but having no limit on core or a
configurable limit different from 10 would make again the new thing
inconsistent with current EventEmitter in node.
Again, I'd rather migrate to a new standard
-1
not only node implemented EventEmitter without even reading what DOM had to
offer before, I see whatever EventEmitter proposal would land in ES7
something related to lightweight traits, and not a class to extend.
Extending EventEmitter without having the ability to extend something else
looks
Just to avoid misunderstanding ...
without even reading what DOM had to offer before
I meant it went out through a pragmatic approach with a non Events based
emit model and few inconsistent choices regarding listeners in terms of
both interface and the inability to interfere with non owned ...
Note that when/if observables land we get an event-emitter mechanism in the
language anyway.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
This same claim could be made about every item in ECMAScript.
Implementation variation in ModuleSpecifiers is no different from variation
in the allowed keywords, character set, or really anything a developer
types. Failing to specify this aspect of the language makes no sense to
this developer
Don't worry. It is going to be spec'ed as part of the module loader spec.
http://whatwg.github.io/loader/
On Mon, Jun 1, 2015 at 10:47 AM John Barton johnjbar...@google.com wrote:
This same claim could be made about every item in ECMAScript.
Implementation variation in ModuleSpecifiers is no
Who is failing to do what now? :-/
/be
John Barton wrote:
This same claim could be made about every item in ECMAScript.
Implementation variation in ModuleSpecifiers is no different from
variation in the allowed keywords, character set, or really anything a
developer types. Failing to
Domenic Denicola wrote:
However, in the end, what you need to do to get something into the language is
to prove that it's a common enough need that it's worth adding complexity to
the spec and implementations. This thread is very far from doing that. A better
start would be surveying
On Monday, June 1, 2015, Tom Van Cutsem tomvc...@gmail.com wrote:
2015-06-01 8:38 GMT+02:00 Domenic Denicola d...@domenic.me
javascript:_e(%7B%7D,'cvml','d...@domenic.me');:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org
2015-06-01 8:38 GMT+02:00 Domenic Denicola d...@domenic.me:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Gray Zhang
I’m just wondering is there any reason that Reflect API is not suitable
to provide such functionality?
Reflect currently contains only methods which
I have lodged the following question on StackOverflow:
http://stackoverflow.com/questions/30564053/how-can-i-synchronously-determine-a-javascript-promises-state
I have also lodged it as a proposal on Specifiction:
Why not just use a subclass of Promise? I don't see why that has to be
part of the base class.
```
class ObservablePromise extends Promise {}
ObservablePromise.prototype.isSettled = function() { return
!!this.isSettled; };
ObservablePromise.prototype.then = function(res, rej) {
return
I will repeat to you what I said on Specifiction:
To get a standard API for this, you'll need to convince the JavaScript
standard committee, as well as the browser vendors, that your use case is
widespread and important enough to be worth the standardization and
implementation burden, and
Alexander Jones wrote:
Or since Proxy traps correspond 1-to-1 to the internal methods
in the spec, the primary goal of the Reflect API was to expose the
essential methods that make up Javascript's object model as
defined by the spec.
I like this definition. Is it written
## legacy use case
I am maintaining an existing API that includes asynchronous functions (mix
of callbacks and Promises) and synchronous functions. After some
asynchronous initialisation, the internal state settles and it is perfectly
safe to use the synchronous functions as expected.
So, I'd
At the May 27-29 TC39 meeting we agreed to make this change.
Allen
On May 7, 2015, at 2:47 PM, C. Scott Ananian wrote:
Hopefully everyone has had a little bit of time to think over the
issues with Promise.resolve().
Last week I proposed three different reasonable semantics for
19 matches
Mail list logo
