Re: Maybe we need a reflect API to iterate over instance members
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 API is not suitable to
provide such functionality?
Best regards
Gray Zhang
在 2015年6月1日 下午12:52:26, Fink Steve (sph...@gmail.com) 写到:
Forgive me for golfing it, but
function getAllPropertyNames(o) {
if (!o) return [];
return Object.getOwnPropertyNames(o) +
getAllPropertyNames(Object.getPrototypeOf(o));
}
or as a generator
function* allPropertyNames(o) {
if (!o) return;
yield* Object.getOwnPropertyNames(o);
yield* allPropertyNames(Object.getPrototypeOf(o));
}
don't seem too onerous.
Though on the other hand, didn't I hear that prototype loops are now possible
with Proxies? If so, then you'd need to handle that.
Then again, if you're going to handle weird cases, then what should it even
return if you go through a Proxy's getPrototypeOf trap that mutates the set of
properties?
On 05/31/2015 04:42 AM, Gray Zhang wrote:
Since class’s members are non-enumerable by default (which is a good choice) we
cannot use for .. in to iterate over all members of an instance, the same
problem could exists in a plain object when we use Object.defineProperty API.
In real world there are some scenarios where we need to iterate over members, A
common example is we need to find all set{SomeThing} methods so we can do an
auto dependency injection.
Certainly we can write a 3rd-party function to find all members through
prototype chain:
function getAllMembersKeys(obj) {
let keys = [];
while (obj) {
keys.push(...Object.getOwnPropertyNames(obj));
obj = Object.getPrototypeOf(obj);
}
return keys;
}
But it doesn’t look nice and lacks considerations of many things such as
Symbol’d keys.
Look around other languages with reflection API, most of them would provide a
method to iterate over all members / properties / methods of an instance, so
why not we provide a set of utility API:
Reflect.getAllMembersNames
Reflect.getAllMemberDescriptors
Reflect.getAllMethodNames
Reflect.getAllMethodDescriptors
Reflect.getAllPropertyNames
Reflect.getAllPropertyDescriptors
Best regards
Gray Zhang
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Maybe we need a reflect API to iterate over instance members
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 beyond that, but making that first step is going to be a hurdle for whoever’s proposing it to extend it. A better place for such methods might be Object.* or some new module or global. 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 open-source code to find usages of this kind of functionality. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal to add EventEmitter to core [ES7]
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 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 than bring EventEmitter as it is from node.js world to core ES.next, and also using traits. Regards On Mon, Jun 1, 2015 at 11:01 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: 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 ... we need a better approach to EventListeners if it has to be implemented in core, something that could work in both client and server world. Again my 2 cents On Mon, Jun 1, 2015 at 10:58 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: -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 like a poor choce to me, having a list of well known traits including the EventEmitter one would be better. About current node implementation: 1. it doesn't accept objects as listeners, a not so common but actully widely used practice on the WEB 2. it does accept multiple times the same listener, a footgun on DOM-land 3. it has a maximum amount of listeners per objects, a footgun on DOM-land 4. it has an `on` method but not an `off`, not convenient on DOM where an app doesn't have same listeners forever due Ajax/client-server interaction nature, I'd like a more consistent naming convention 5. it exposes the ability to remove/retrieve listeners you don't own, again a footgun on DOM or anywhere the code is own by multiple libraries and authors Just my 2 cents. Regards On Sun, May 31, 2015 at 6:46 PM, aakarsh1997 aakarsh1...@gmail.com wrote: Hi, I propose the inclusion of the node/io EventEmitter class[1] in core targeting ES7. Reasoning: The .on/.emit model is very popular[2] in the ECMAScript land, and it suits the language a lot. We use events pretty much everywhere in the JS land. It makes sense for the standard EventEmitter class used commonly to be included in core. With ES6 classes, userland code classes extending[3] the EventEmitter class would be pretty common and useful even in environments like browsers. Notes: I think the `.once` method from the node/io EventEmitter class _could_ be left out from standard implementation mainly because we would rather use Promises there. Although it would also make sense to keep it in for further compatibility. [1] https://iojs.org/api/events.html [2] https://github.com/search?l=JavaScriptq=eventemitterref=opensearchtype=Code [3] https://github.com/search?p=2q=extends+eventemitterref=searchresultstype=Codeutf8=%E2%9C%93 ___ 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
Re: Proposal to add EventEmitter to core [ES7]
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 than bring EventEmitter as it is from node.js world to core ES.next, and also using traits. Regards On Mon, Jun 1, 2015 at 11:01 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: 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 ... we need a better approach to EventListeners if it has to be implemented in core, something that could work in both client and server world. Again my 2 cents On Mon, Jun 1, 2015 at 10:58 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: -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 like a poor choce to me, having a list of well known traits including the EventEmitter one would be better. About current node implementation: 1. it doesn't accept objects as listeners, a not so common but actully widely used practice on the WEB 2. it does accept multiple times the same listener, a footgun on DOM-land 3. it has a maximum amount of listeners per objects, a footgun on DOM-land 4. it has an `on` method but not an `off`, not convenient on DOM where an app doesn't have same listeners forever due Ajax/client-server interaction nature, I'd like a more consistent naming convention 5. it exposes the ability to remove/retrieve listeners you don't own, again a footgun on DOM or anywhere the code is own by multiple libraries and authors Just my 2 cents. Regards On Sun, May 31, 2015 at 6:46 PM, aakarsh1997 aakarsh1...@gmail.com wrote: Hi, I propose the inclusion of the node/io EventEmitter class[1] in core targeting ES7. Reasoning: The .on/.emit model is very popular[2] in the ECMAScript land, and it suits the language a lot. We use events pretty much everywhere in the JS land. It makes sense for the standard EventEmitter class used commonly to be included in core. With ES6 classes, userland code classes extending[3] the EventEmitter class would be pretty common and useful even in environments like browsers. Notes: I think the `.once` method from the node/io EventEmitter class _could_ be left out from standard implementation mainly because we would rather use Promises there. Although it would also make sense to keep it in for further compatibility. [1] https://iojs.org/api/events.html [2] https://github.com/search?l=JavaScriptq=eventemitterref=opensearchtype=Code [3] https://github.com/search?p=2q=extends+eventemitterref=searchresultstype=Codeutf8=%E2%9C%93 ___ 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
Re: Proposal to add EventEmitter to core [ES7]
-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 like a poor choce to me, having a list of well known traits including the EventEmitter one would be better. About current node implementation: 1. it doesn't accept objects as listeners, a not so common but actully widely used practice on the WEB 2. it does accept multiple times the same listener, a footgun on DOM-land 3. it has a maximum amount of listeners per objects, a footgun on DOM-land 4. it has an `on` method but not an `off`, not convenient on DOM where an app doesn't have same listeners forever due Ajax/client-server interaction nature, I'd like a more consistent naming convention 5. it exposes the ability to remove/retrieve listeners you don't own, again a footgun on DOM or anywhere the code is own by multiple libraries and authors Just my 2 cents. Regards On Sun, May 31, 2015 at 6:46 PM, aakarsh1997 aakarsh1...@gmail.com wrote: Hi, I propose the inclusion of the node/io EventEmitter class[1] in core targeting ES7. Reasoning: The .on/.emit model is very popular[2] in the ECMAScript land, and it suits the language a lot. We use events pretty much everywhere in the JS land. It makes sense for the standard EventEmitter class used commonly to be included in core. With ES6 classes, userland code classes extending[3] the EventEmitter class would be pretty common and useful even in environments like browsers. Notes: I think the `.once` method from the node/io EventEmitter class _could_ be left out from standard implementation mainly because we would rather use Promises there. Although it would also make sense to keep it in for further compatibility. [1] https://iojs.org/api/events.html [2] https://github.com/search?l=JavaScriptq=eventemitterref=opensearchtype=Code [3] https://github.com/search?p=2q=extends+eventemitterref=searchresultstype=Codeutf8=%E2%9C%93 ___ 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
Re: Proposal to add EventEmitter to core [ES7]
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 ... we need a better approach to EventListeners if it has to be implemented in core, something that could work in both client and server world. Again my 2 cents On Mon, Jun 1, 2015 at 10:58 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: -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 like a poor choce to me, having a list of well known traits including the EventEmitter one would be better. About current node implementation: 1. it doesn't accept objects as listeners, a not so common but actully widely used practice on the WEB 2. it does accept multiple times the same listener, a footgun on DOM-land 3. it has a maximum amount of listeners per objects, a footgun on DOM-land 4. it has an `on` method but not an `off`, not convenient on DOM where an app doesn't have same listeners forever due Ajax/client-server interaction nature, I'd like a more consistent naming convention 5. it exposes the ability to remove/retrieve listeners you don't own, again a footgun on DOM or anywhere the code is own by multiple libraries and authors Just my 2 cents. Regards On Sun, May 31, 2015 at 6:46 PM, aakarsh1997 aakarsh1...@gmail.com wrote: Hi, I propose the inclusion of the node/io EventEmitter class[1] in core targeting ES7. Reasoning: The .on/.emit model is very popular[2] in the ECMAScript land, and it suits the language a lot. We use events pretty much everywhere in the JS land. It makes sense for the standard EventEmitter class used commonly to be included in core. With ES6 classes, userland code classes extending[3] the EventEmitter class would be pretty common and useful even in environments like browsers. Notes: I think the `.once` method from the node/io EventEmitter class _could_ be left out from standard implementation mainly because we would rather use Promises there. Although it would also make sense to keep it in for further compatibility. [1] https://iojs.org/api/events.html [2] https://github.com/search?l=JavaScriptq=eventemitterref=opensearchtype=Code [3] https://github.com/search?p=2q=extends+eventemitterref=searchresultstype=Codeutf8=%E2%9C%93 ___ 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
Re: Proposal to add EventEmitter to core [ES7]
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
Re: import ModuleSpecifier
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 at least. On Sun, May 31, 2015 at 7:30 PM, Brendan Eich bren...@mozilla.org wrote: Browsers in any semi-competitive market will agree on a standard. I don't see why that needs to be called into doubt, even as part of a hypothetical future :-|. (Is there another kind? :-P) /be Domenic Denicola wrote: Yes, in theory. However, browsers are more likely to wait until there’s a standard for browser module loaders before shipping modules, in order to avoid such divergent behavior. ___ 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
Re: import ModuleSpecifier
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 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 at least. On Sun, May 31, 2015 at 7:30 PM, Brendan Eich bren...@mozilla.org wrote: Browsers in any semi-competitive market will agree on a standard. I don't see why that needs to be called into doubt, even as part of a hypothetical future :-|. (Is there another kind? :-P) /be Domenic Denicola wrote: Yes, in theory. However, browsers are more likely to wait until there’s a standard for browser module loaders before shipping modules, in order to avoid such divergent behavior. ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: import ModuleSpecifier
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 specify this aspect of the language makes no sense to this developer at least. On Sun, May 31, 2015 at 7:30 PM, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: Browsers in any semi-competitive market will agree on a standard. I don't see why that needs to be called into doubt, even as part of a hypothetical future :-|. (Is there another kind? :-P) /be Domenic Denicola wrote: Yes, in theory. However, browsers are more likely to wait until there’s a standard for browser module loaders before shipping modules, in order to avoid such divergent behavior. ___ es-discuss mailing list es-discuss@mozilla.org mailto: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
Re: Maybe we need a reflect API to iterate over instance members
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 open-source code to find usages of this kind of functionality. Bingo. Proof is a convincing argument, really an empircal study of some not-too-small N samples. Kevin Smith's analysis of = utility based on cases where functions are verbose and do or do not want `this` bound, taking into account concise methods from ES6, is a good example. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maybe we need a reflect API to iterate over instance members
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 javascript:_e(%7B%7D,'cvml','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 beyond that, but making that first step is going to be a hurdle for whoever’s proposing it to extend it. 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 down? (I need ammunition for Reflect.type(x)!) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maybe we need a reflect API to iterate over instance members
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 correspond to proxy traps. There has been talk of extending it beyond that, but making that first step is going to be a hurdle for whoever’s proposing it to extend it. 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. There are many utility methods one may want to add on top, but it seems better to wait and see what the community comes up with rather than to try to codify an extensive API before it has seen any significant use. Regarding duplicates: ES6 has Sets. It should be fairly straightforward to adapt the above example to de-dup inherited property names. Regards, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
How can I synchronously determine a JavaScript Promise's state?
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:
http://discourse.specifiction.org/t/how-can-i-synchronously-determine-a-javascript-promises-state/866
I have a pure JavaScript Promise (built-in implementation or poly-fill):
`var promise = new Promise(function (resolve, reject) { /* ... */ });`
From the [specification](
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects),
a Promise can be one of:
- 'settled' and 'resolved'
- 'settled' and 'rejected'
- 'pending'
I have a use case where I wish to interrogate the Promise synchronously and
determine:
- is the Promise settled?
- if so, is the Promise resolved?
It appears there is no API for synchronous interrogation of a Promise's
state. Can we please make this part of a future specification?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: How can I synchronously determine a JavaScript Promise's state?
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 super.then(
function(x) { this.isSettled = true; return res(x); },
function(e) { this.isSettled = true; return rej(x); }
);
}
// etc
```
--scott
On Mon, Jun 1, 2015 at 5:29 PM, Ron Waldon jokeyrh...@gmail.com wrote:
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:
http://discourse.specifiction.org/t/how-can-i-synchronously-determine-a-javascript-promises-state/866
I have a pure JavaScript Promise (built-in implementation or poly-fill):
`var promise = new Promise(function (resolve, reject) { /* ... */ });`
From the [specification](
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects),
a Promise can be one of:
- 'settled' and 'resolved'
- 'settled' and 'rejected'
- 'pending'
I have a use case where I wish to interrogate the Promise synchronously
and determine:
- is the Promise settled?
- if so, is the Promise resolved?
It appears there is no API for synchronous interrogation of a Promise's
state. Can we please make this part of a future specification?
___
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
RE: How can I synchronously determine a JavaScript Promise's state?
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 that it cannot be achieved in any other possible way. So ... go! Looking forward to your use cases, preferably with examples showing code in popular libraries or apps that would benefit to illustrate how wide-spread those use cases are. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maybe we need a reflect API to iterate over instance members
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 down? (I need ammunition for Reflect.type(x)!) You have my axe! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How can I synchronously determine a JavaScript Promise's state?
## 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 like to emit warnings when these synchronous functions are called prior to a Promise being settled. That way, downstream developers will know that they should be waiting for the Promise to settle before using such functions. This actually isn't too different to the XHR / Fetch APIs conceptually. We get the ball rolling with an asynchronous API call, but there are deterministic blocks within which we can synchronously interrogate progress, etc. ## activity indicator use case I use a Promise to represent a network transaction. I wish to alter the visual state of my web app to reflect the state of this network transaction. I can, for example, show an indeterminate progress bar whilst the Promise is not settled. If I am using requestAnimationFrame, or a framework like React, then the state would be synchronously mapped to the DOM / canvas during each execution of my render function. I can track the state of the Promise using additional variables (as others have suggested), but those state values already exist somewhere private per the functioning of a Promise. I'd be duplicating work that the JavaScript engine is already performing internally, at the risk of introducing errors in my code. ## third-party popular libraries The following libraries implement some form of Promise and all expose such synchronous inspection capabilities: - jQuery: http://api.jquery.com/deferred.state/ - Bluebird: https://github.com/petkaantonov/bluebird/blob/master/API.md#synchronous-inspection - Q: https://github.com/kriskowal/q/wiki/API-Reference#state-inspection-methods - Lie: https://github.com/calvinmetcalf/lie/blob/master/lib/promise.js#L17 On Tue, 2 Jun 2015 at 07:31 Domenic Denicola d...@domenic.me wrote: 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 that it cannot be achieved in any other possible way. So ... go! Looking forward to your use cases, preferably with examples showing code in popular libraries or apps that would benefit to illustrate how wide-spread those use cases are. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Fixing `Promise.resolve()`
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 `Promise.resolve`, none of which involve the `[[PromiseConstructor]]` internal field: https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50 I continue to feel that the no species proposal is the best alternative, reasoning that `Promise.resolve` is more like an explicit constructor than an species-using instance-transformation method. Here's that proposal again: Promise.resolve(x) 1. Let C be the this value. 2. If IsPromise(x) is true, a. Let constructor be the value of Get(x, constructor). b. ReturnIfAbrupt(constructor) c. If SameValue(constructor, C) is true, return x. 3. Let promiseCapability be NewPromiseCapability(C). 4. ReturnIfAbrupt(promiseCapability). 5. Let resolveResult be Call(promiseCapability.[[Resolve]], undefined, «x»). 6. ReturnIfAbrupt(resolveResult). 7. Return promiseCapability.[[Promise]]. All mentions of [[PromiseConstructor]] should then be garbage-collected from the spec. This simplifies the semantics and fixes the hidden new.target brokenness which affects interoperability with code written in ES5 syntax. Eliminating species here also yields more useful behavior from `P.resolve` if an subclass sets `P[Symbol.species] !== P`. It's my understanding that Mark Miller volunteered to champion the changes to `Promise.resolve` at the next TC39 meeting. (Thanks, Mark!). I'll update `es6-shim` and `core-js`/`babel` if/when TC39 reaches consensus on this. Thanks! --scott ___ 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
