Replies interspersed below
On Thu, Apr 23, 2015 at 9:48 AM, James Burke jrbu...@gmail.com wrote:
On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola d...@domenic.me wrote:
Indeed, there is no built-in facility for bundling since as explained
in this thread that will actually slow down your
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
What I do is send the files over in as TAR archives, with mod_deflate
turned on (they basically turn into .tar.gz files at that point). It's
reasonably fast, even though I'm processing thirty megabytes of data this
way (yay for typed arrays). I highly recommend it.
On Thu, Apr 23, 2015 at 7:57
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.
Thanks! Had completely missed that GH repo's existence. :)
Cool that this is moving forward!
Thanks to Sebastian for the explanation as well!
On Thu, 23 Apr 2015 18:46 Michael Ficarra mfica...@shapesecurity.com
wrote:
See https://github.com/tc39/ecma262. This proposal is currently at stage
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
11 matches
Mail list logo
