On Wed, Apr 29, 2015 at 6:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
The another test that you propose seems to be exactly the fix which
Brandon proposed and I codified, to wit:
2. If IsPromise(x) is true,
a. Let constructor be the value of SpeciesConstructor(x, %Promise%)
Just to close the loop on this, regarding the main point I remain convinced
and would be happy to champion. Again, thanks for pushing on this.
More later
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
On Apr 29, 2015, at 8:44 AM, C. Scott Ananian wrote:
On Wed, Apr 29, 2015 at 1:06 AM, Brendan Eich bren...@mozilla.org wrote:
Kevin Smith wrote:
So what would the ideal Promise.resolve semantics do? I'm not sure, maybe
use SpeciesConstructor instead of [[PromiseConstructor]]?
This
On Wed, Apr 29, 2015 at 1:06 AM, Brendan Eich bren...@mozilla.org wrote:
Kevin Smith wrote:
So what would the ideal Promise.resolve semantics do? I'm not sure,
maybe use SpeciesConstructor instead of [[PromiseConstructor]]?
This removes the wart in my view, has no less integrity. C.
On Wed, Apr 29, 2015 at 12:49 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 29, 2015, at 8:44 AM, C. Scott Ananian wrote:
On Wed, Apr 29, 2015 at 1:06 AM, Brendan Eich bren...@mozilla.org wrote:
Kevin Smith wrote:
So what would the ideal Promise.resolve semantics do? I'm not
On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote:
On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
class DefensivePromise extends Promise {
constructor(x) {
super(x);
On Wed, Apr 29, 2015 at 11:12 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Wed, Apr 29, 2015 at 2:07 PM, Mark S. Miller erig...@google.com
wrote:
Hi Scott, I think your approach is on the right track. How about the
following?
Anyone see a way to attack it?
const goodPromises =
On Apr 29, 2015, at 12:40 PM, C. Scott Ananian wrote:
On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote:
On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
class
On Wed, Apr 29, 2015 at 12:40 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote:
On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com
On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
class DefensivePromise extends Promise {
constructor(x) {
super(x);
if (new.target === DefensivePromise) {
// I'm assuming this test is just to be subclass friendly and
allow subclasses to
On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote:
On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
class DefensivePromise extends Promise {
constructor(x) {
super(x);
if (new.target === DefensivePromise) {
// I'm assuming this test
On Wed, Apr 29, 2015 at 2:07 PM, Mark S. Miller erig...@google.com wrote:
Hi Scott, I think your approach is on the right track. How about the
following?
Anyone see a way to attack it?
const goodPromises = new WeakSet();
class DefensivePromise {
constructor(x) {
super(x);
if
I do indeed need to expose DefensivePromise under the global name
Promise, replacing the builtin. Other than itself being frozen and making
frozen promises, it should in all other ways conform exactly to the promise
spec while still guaranteeing this invariant.
```
constructor(x) {
On Wed, Apr 29, 2015 at 1:00 PM, Mark S. Miller erig...@google.com wrote:
The invariant I am interested in:
In a realm where we (the trusted defender who runs first) make Promise
defensive as follows
* Freeze everything primordial, as SES does
* Make a DefensivePromise subclass of Promise
On Wed, Apr 29, 2015 at 10:26 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Wed, Apr 29, 2015 at 1:00 PM, Mark S. Miller erig...@google.com
wrote:
The invariant I am interested in:
In a realm where we (the trusted defender who runs first) make Promise
defensive as follows
* Freeze
const goodPromises = new WeakSet();
class DefensivePromise {
constructor(x) {
super(x);
if (new.target === DefensivePromise) {
Object.freeze(this);
goodPromises.add(this);
}
}
static resolve(x) {
if (goodPromises.has(x)) {
return x; // should
```
constructor(x) {
super(x);
Object.defineProperties(this, { then: { value: this.then }});
Object.freeze(this);
if (this.constructor==DefensivePromise this.then ===
DefensivePromise.prototype.then) {
goodPromises.add(this);
}
}
```
Getting closer, I hope!
I also
On Wed, Apr 29, 2015 at 2:36 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
[...]
Mark, after you've slept on this and assuming you haven't changed your
mind, would you be willing to be the TC39 champion? I'm not a participant
in that process.
Yes.
--
Cheers,
--MarkM
On Apr 29, 2015, at 2:44 PM, Mark S. Miller wrote:
On Wed, Apr 29, 2015 at 2:36 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
[...]
Mark, after you've slept on this and assuming you haven't changed your mind,
would you be willing to be the TC39 champion? I'm not a participant in that
On Wed, Apr 29, 2015 at 4:16 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 29, 2015, at 12:40 PM, C. Scott Ananian wrote:
On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote:
On Wed, Apr 29, 2015
Allen Wirfs-Brock wrote:
Regardless, too late for ES2015. It will have to proposed as an
ES2016 change.
Could we errata quickly? Implementations should not ship the bug.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
On Apr 29, 2015, at 2:36 PM, C. Scott Ananian wrote:
On Wed, Apr 29, 2015 at 4:16 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 29, 2015, at 12:40 PM, C. Scott Ananian wrote:
On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Apr 29, 2015, at
Allen Wirfs-Brock wrote:
But the specified [[PromiseConstructor]] test doesn't really hurt
anything.
I've heard that before!
It's a wart implementations can avoid shipping, to avoid Murphy's-Law
compatibility constraints growing on top of it. You don't want a wart at
all, certainly not
So, ES6 Promises reflect a specific set of design decisions, including a
specific definition of same type that appears to exist solely for use by
Promise.resolve. All that design guarantees is that the object has an
certain specific internal slot whose value is tested in a specific way by
Le 26 avr. 2015 à 00:58, Kevin Smith zenpars...@gmail.com a écrit :
If we used x.constructor to determine the actual constructor, then someone
could just change the constructor property for x and fool someone who wrote
C.resolve(x) and expected to get an instance of C back.
Note that if
Domenic, Kevin: the concern about Reflect.construct seems misplaced, but
in any event, the issue C. Scott raises wants addressing on its own. WDYT?
Yeah, sorry for dwelling on Reflect.construct so much (it's in my mind for
other reasons).
So what would the ideal Promise.resolve semantics do?
Kevin Smith wrote:
So what would the ideal Promise.resolve semantics do? I'm not sure,
maybe use SpeciesConstructor instead of [[PromiseConstructor]]?
This removes the wart in my view, has no less integrity. C. Scott?
/be
___
es-discuss mailing
C. Scott Ananian wrote:
It seems to me that this is an incomplete feature that should have
been dropped from the spec.
Seems like.
I apologize for not noticing this sooner.
No need -- thanks for finding it.
Domenic, Kevin: the concern about Reflect.construct seems misplaced, but
in any
On Apr 28, 2015, at 1:08 PM, Kevin Smith wrote:
What is the use case for third argument to Reflect.construct?
The primary use case is emulating the super() call semantics in a Proxy
construct trap handler.
Allen
___
es-discuss mailing list
2015-04-28 5:01 GMT+02:00 Kevin Smith zenpars...@gmail.com:
Looking over the Reflect namespace, I also see that Reflect.get and
Reflect.set have been given powers not expressible with syntax: the
receiver does not have to be a prototype parent of the target.
Did you mean the receiver does
On Apr 27, 2015, at 8:01 PM, Kevin Smith wrote:
x = Reflect.construct(Promise, x, C);
is another fine way to fool someone who wrote C.resolve(x) and expected to
get an instance of C back.
Thanks for pointing this out. I believe the ability to use an arbitrary
newTarget parameter for
On Tue, Apr 28, 2015 at 2:41 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
So, ES6 Promises reflect a specific set of design decisions, including a
specific definition of same type that appears to exist solely for use by
Promise.resolve. All that design guarantees is that the object has
x = Reflect.construct(Promise, x, C);
is another fine way to fool someone who wrote C.resolve(x) and expected
to get an instance of C back.
Thanks for pointing this out. I believe the ability to use an arbitrary
newTarget parameter for Reflect.construct is breaking the intent of
On Sat, Apr 25, 2015 at 5:03 PM, Domenic Denicola d...@domenic.me wrote:
There needs to be an unforgable brand property such that only objects
created with `new XPromise()` pass `XPromise.resolve`. It is not a use case
to allow building an object ES5 style in pieces to pass the brand check.
Inadvertently moved discussion off-list; requoting on list:
On Sat, Apr 25, 2015 at 4:33 PM, Domenic Denicola d...@domenic.me wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of C.
Scott Ananian
But in the code given previously, I've used `Object.setPrototypeOf` to
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of C. Scott
Ananian
But in the code given previously, I've used `Object.setPrototypeOf` to
effectively change the type of the object -- but [[PromiseConstructor]]
doesn't follow along.
That is exactly the kind of tampering
I think I'd rather see `Promise.resolve` changed to use `this.constructor`
instead of `this.[[PromiseConstructor]]`, like every other Promise-related
method. Can someone who feels strongly otherwise give me the use case for
`[[PromiseConstructor]]` existing?
I'll give it a shot.
On Fri, Apr 24, 2015 at 11:31 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Fri, Apr 24, 2015 at 10:46 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
So you should do the same with Promise methods but then you'll see
overall a quite consistent performance drop when using
On Sat, Apr 25, 2015 at 6:58 PM, Kevin Smith zenpars...@gmail.com wrote:
I think I'd rather see `Promise.resolve` changed to use `this.constructor`
instead of `this.[[PromiseConstructor]]`, like every other Promise-related
method. Can someone who feels strongly otherwise give me the use case
It's possible Reflect.construct has introduced a security hole that was not
present before the recent instantiation reform. Hopefully Mark can comment more.
On Sat, Apr 25, 2015 at 9:52 PM -0700, C. Scott Ananian
ecmascr...@cscott.netmailto:ecmascr...@cscott.net wrote:
On Sat, Apr 25,
On Sun, Apr 26, 2015 at 12:56 AM, Domenic Denicola d...@domenic.me wrote:
It's possible Reflect.construct has introduced a security hole that was
not present before the recent instantiation reform. Hopefully Mark can
comment more.
Note that, even without `Reflect.construct`:
```
x = new
Not exactly ... if it's an Array, as example, the moment you
slice/map/splice/concat, etc will return an instanceof Array, not an
instance of whatever you have sublcassed.
Regards
On Fri, Apr 24, 2015 at 10:24 AM, Alex Kocharin a...@kocharin.ru wrote:
I believe you can subclass anything using
I believe you can subclass anything using code like this: function MyPromise(executor) { var self = new Promise(executor) self.setPrototypeOf(self, MyPromise.prototype) return self}Object.setPrototypeOf(MyPromise, Promise) ... and it can be easily subclassed itself in the same way.
True, but it should be your responsibility (as a person who implements a subclass) to resolve those issues. Thankfully, it's easily done: ```function MyArray(...args) { var self = Array.apply(null, args) Object.setPrototypeOf(self, MyArray.prototype) return self}
On Fri, Apr 24, 2015 at 10:46 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
So you should do the same with Promise methods but then you'll see overall
a quite consistent performance drop when using all these subclasses.
Well, not exactly. The Promise methods are all written to
So you should do the same with Promise methods but then you'll see overall
a quite consistent performance drop when using all these subclasses.
We've been trying for about 10 years now (
http://dean.edwards.name/weblog/2006/11/hooray/ ) and yet we don't have a
working and performing solution,
Le 24 avr. 2015 à 03:25, Caitlin Potter caitpotte...@gmail.com a écrit :
So, why exactly is SuperCall forbidden in function bodies? If people work
around it with Reflect.construct anyways, it just seems nice to use SuperCall
instead — at least if new.target is defined
Note that
new.target is available in functions.
On Thu, Apr 23, 2015, 21:02 C. Scott Ananian ecmascr...@cscott.net wrote:
Is there any way to access `new.target` using ES5 syntax?
It appears that the correct way to create a subclass using ES5 syntax is:
```
function MyPromise(executor) {
var self
So, why exactly is SuperCall forbidden in function bodies? If people work
around it with Reflect.construct anyways, it just seems nice to use SuperCall
instead — at least if new.target is defined
On Apr 23, 2015, at 9:24 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
new.target is
49 matches
Mail list logo
