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
https://mail.mozill
On Wed, Apr 29, 2015 at 6:32 PM, Allen Wirfs-Brock
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%)
>> b. If Same
On Apr 29, 2015, at 2:36 PM, C. Scott Ananian wrote:
> On Wed, Apr 29, 2015 at 4:16 PM, Allen Wirfs-Brock
> 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
>> wrote:
>> On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote:
>
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 with
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
https://mail.mozilla.org
On Apr 29, 2015, at 2:44 PM, Mark S. Miller wrote:
> On Wed, Apr 29, 2015 at 2:36 PM, C. Scott Ananian
> 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.
>
>
On Wed, Apr 29, 2015 at 2:36 PM, C. Scott Ananian
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 Wed, Apr 29, 2015 at 4:16 PM, Allen Wirfs-Brock
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
> 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 >
On Apr 29, 2015, at 12:40 PM, C. Scott Ananian wrote:
> On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock
> 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
>> wrote:
>> class DefensivePromise extends Promise {
>> constru
On Wed, Apr 29, 2015 at 12:40 PM, C. Scott Ananian
wrote:
> On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock
> 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 > > wrote:
>>
>>> class DefensivePromise extends Promise {
On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock
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
> wrote:
>
>> class DefensivePromise extends Promise {
>> constructor(x) {
>> super(x);
>> if (new.target === Defens
On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote:
> On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock
> wrote:
> class DefensivePromise extends Promise {
> constructor(x) {
> super(x);
> if (new.target === DefensivePromise) {
>// I'm assuming this test is just to be
On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock
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 freeze later?
>
```
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 al
>
> 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;
On Wed, Apr 29, 2015 at 11:12 AM, C. Scott Ananian
wrote:
> On Wed, Apr 29, 2015 at 2:07 PM, Mark S. Miller
> 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();
>> cla
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 2:07 PM, Mark S. Miller 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 (new.t
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 (new.target === DefensivePromise) {
Object.freeze(this);
goodPromises.a
On Wed, Apr 29, 2015 at 1:37 PM, Mark S. Miller wrote:
> On Wed, Apr 29, 2015 at 10:26 AM, C. Scott Ananian
> wrote:
>
>> On Wed, Apr 29, 2015 at 1:00 PM, Mark S. Miller
>> wrote:
>>
>>> The invariant I am interested in:
>>>
>>> In a realm where we (the trusted defender who runs first) make Pro
On Wed, Apr 29, 2015 at 10:26 AM, C. Scott Ananian
wrote:
> On Wed, Apr 29, 2015 at 1:00 PM, Mark S. Miller
> 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, a
On Wed, Apr 29, 2015 at 1:00 PM, Mark S. Miller 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 that diffe
On Wed, Apr 29, 2015 at 12:49 PM, Allen Wirfs-Brock
wrote:
> On Apr 29, 2015, at 8:44 AM, C. Scott Ananian wrote:
>
On Wed, Apr 29, 2015 at 1:06 AM, Brendan Eich wrote:
>
> Kevin Smith wrote:
>>
>>> So what would the ideal Promise.resolve semantics do? I'm not sure,
>>> maybe use SpeciesConstru
I have not responded on list yet because I haven't yet been able to find
the time to absorb this thread. But since Allen mentioned it, what I wrote
was:
The invariant I am interested in:
In a realm where we (the trusted defender who runs first) make Promise
defensive as follows
* Freeze everyt
On Apr 29, 2015, at 8:44 AM, C. Scott Ananian wrote:
> On Wed, Apr 29, 2015 at 1:06 AM, Brendan Eich 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
On Wed, Apr 29, 2015 at 1:06 AM, Brendan Eich 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. Scott?
Making
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 list
>
> 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
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 ev
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
es-d
>
> 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
On Tue, Apr 28, 2015 at 2:41 PM, Allen Wirfs-Brock
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 an
> certain spec
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 parame
2015-04-28 5:01 GMT+02:00 Kevin Smith :
> 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 not have to be a
> Le 26 avr. 2015 à 00:58, Kevin Smith 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 you want t
>
> 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
Pro
On Sun, Apr 26, 2015 at 12:56 AM, Domenic Denicola 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 C(); // C some
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"
mailto:ecmascr...@cscott.net>> wrote:
On Sat, Apr 25, 2015 at 6:58 PM, Kevi
On Sat, Apr 25, 2015 at 6:58 PM, Kevin Smith 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 for
>> `[[Promis
>
> 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.
"Pro
On Sat, Apr 25, 2015 at 5:03 PM, Domenic Denicola 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.
> Such objects
Inadvertently moved discussion off-list; requoting on list:
On Sat, Apr 25, 2015 at 4:33 PM, Domenic Denicola 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
> effective
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 tamperin
On Fri, Apr 24, 2015 at 11:31 AM, C. Scott Ananian
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 all these subcl
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 t
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, whic
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} Object.setPrototypeOf(MyArray.p
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 wrote:
>
> I believe you can subclass anything using code like this
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. 24.04.2015
> Le 24 avr. 2015 à 03:25, Caitlin Potter 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 `super(...)` will try to in
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 wrote:
>
> new.target is available in functions.
>
new.target is available in functions.
On Thu, Apr 23, 2015, 21:02 C. Scott Ananian 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 = Reflect.cons
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 = Reflect.construct(Promise, [executor], new.target);
return self;
}
Object.setPrototypeOf(MyPromise, Promise);
```
53 matches
Mail list logo
