The current way to write what you want is:
await Promise.all(itemsCursor.map(item => db.insert(item));
or
await Promise.all(itemsCursor.map(Promise.guard(5, item =>
db.insert(item;
if you are using a library like `prfun` (
https://github.com/cscott/prfun#promiseguardfunctionnumber-condition
"keyword function" might not be too bad, either...
--scott
On Sat, Apr 7, 2018 at 2:32 PM, Naveen Chawla wrote:
> "function" function is the best out of all of the alternatives you
> mentioned.
>
> "Anonymous function declared with the function keyword" if it's not too
> wordy.
>
> On Sat, 7 Ap
To be super explicit: given an array 'a', then: `Array.from(a).sort()` will
return you a sorted clone. That works even if `a` has an iterator or is an
array-like object. That's just seven characters longer than
`Array.sort(a)`, which is what you seem to be proposing.
To be sure, I don't think th
This is the parsing side equivalent to "canonicalized". Any
security-sensitive application of "canonical JSON" should have a strict
verifier confirming that the input is canonical; this verifier would
presumably also throw for out-of-range numbers as you suggest.
--scott
On Sun, Mar 18, 2018, 9
tt
On Sun, Mar 18, 2018, 2:48 PM Anders Rundgren
wrote:
> On 2018-03-18 19:08, C. Scott Ananian wrote:
> > On Fri, Mar 16, 2018 at 9:42 PM, Anders Rundgren <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
> wrote:
> >
> >
On Fri, Mar 16, 2018 at 9:42 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:
> Scott A:
> https://en.wikipedia.org/wiki/Security_level
> "For example, SHA-256 offers 128-bit collision resistance"
> That is, the claims that there are cryptographic issues w.r.t. to Unicode
> Normalizatio
On Sun, Mar 18, 2018, 10:30 AM Anders Rundgren <
anders.rundgren@gmail.com> wrote:
> Violently agree but do not understand (I guess I'm just dumb...) why (for
> example) sorting on UCS2/UTF-16 Code Units would not achieve the same goal
> (although the result would differ).
>
Because there are
My main feedback is that since this topic has been covered so many times in
the past, any serious standardization proposal should include a section
surveying existing "canonical JSON" standards and implementations and
comparing the proposed standard with prior work. A standard should be a
"best of
On Fri, Mar 16, 2018 at 4:07 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:
> Perfection is often the enemy of good.
>
So, to be clear: you don't plan on actually incorporating any feedback into
your proposal, since it's already "good"?
--scott
_
I think the horse is out of the barn re hashable-vs-canonical. It has
(independently) been invented and named canonical JSON many many times,
starting 11 years ago.
https://gibson042.github.io/canonicaljson-spec/
https://www.npmjs.com/package/another-json
https://www.npmjs.com/package/canonical-j
And just to be clear: I'm all for standardizing a canonical JSON form. In
addition to my 11-year-old attempt, there have been countless others, and
still no *standard*. I just want us to learn from the previous attempts
and try to make something at least as good as everything which has come
befor
On Fri, Mar 16, 2018 at 1:30 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:
> On 2018-03-16 18:04, Mike Samuel wrote:
>
> It is entirely unsuitable to embedding in HTML or XML though.
>> IIUC, with an implementation based on this
>>
>>JSON.canonicalize(JSON.stringify("")) === `""`
On Fri, Mar 16, 2018 at 12:23 PM, Mike Samuel wrote:
>
>
> On Fri, Mar 16, 2018 at 11:38 AM, C. Scott Ananian
> wrote:
>
>> Canonical JSON is often used to imply a security property: two JSON blobs
>> with identical contents are expected to have identical canoni
trict mode for
JSON.stringify().
--scott
On Fri, Mar 16, 2018 at 4:48 AM, Anders Rundgren <
anders.rundgren....@gmail.com> wrote:
> On 2018-03-16 08:52, C. Scott Ananian wrote:
>
>> See http://wiki.laptop.org/go/Canonical_JSON -- you should probably at
>> least
>>
See http://wiki.laptop.org/go/Canonical_JSON -- you should probably at
least mention unicode normalization of strings. You probably should also
specify a validator: it doesn't matter if you emit canonical JSON if you
can tweak the hash of the value by feeding non-canonical JSON as an input.
--sc
Promise dispatch should actually simplify to this in certain common cases.
I meant to write up a document describing the typical dispatch
optimizations high-performance Promise libraries do, based on my
experiences writing https://github.com/cscott/babybird (although
Optimization Notes in the READM
Here's a quick plug for my `prfun` library (https://github.com/cscott/prfun)
which implements this as `Promise.delay(1000)`.
API at:
https://github.com/cscott/prfun#promisedelaydynamic-value-int-ms--promise
You can also do `return somepromise.delay(100)` which resolves to the same
value as `samep
`arr.slice(-1)[0]` does what you want, I think.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, May 21, 2014 at 8:33 AM, Claude Pache
wrote:
>
> I have thought about the right semantics (and the issues) of the
> existential operator.
>
> user.getPlan?().value?.score;
>
> The intended semantics of `?` is that, whenever its LHS evaluates to
> `null` or `undefined`,
> the evaluatio
On Wed, Nov 18, 2015 at 6:50 PM, Domenic Denicola wrote:
> All uses of @@species are to be removed from Promise.race and Promise.all.
> The committee achieved consensus on this, without you.
>
To be precise, steps 3-5 are to be removed entirely from Promise.all
(25.4.4.1) and Promise.race (25.4.
sensus has been reached (except perhaps by default, since no one has
advocated for alternatives).
--scott
On 11/4/15 11:22 PM, C. Scott Ananian wrote:
> see my previous message for the exact wording proposal which
> changes step 6.
>
https://esdiscuss.org/topic/performpromiseall#content-6
On Fri, Nov 6, 2015 at 1:20 PM, Brian Terlson
wrote:
> RegExp.re or similar seems nice:
>
> ```
> let re = RegExp.re("x")`
> (\d{3}-)? # area code (optional)
> \d{3}-# prefix
> \d{4} # line number
> `;
> ```
>
> But it seems like previous proposals of this want escaping which d
We have a template string mechanism, and it allows linefeeds. Let's
use that, instead of inventing new heredoc syntax.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
If you're using string templates, why not do the full regex there,
instead of just passing the result to `new RegExp`?
See https://esdiscuss.org/topic/regexp-escape#content-22 and
https://esdiscuss.org/topic/regexp-escape#content-28 for some
examples, and
https://github.com/benjamingr/RegExp.esca
The spec has been implemented as is by both `es6-shim` and `core-js`, and
there are plenty of users of these. So it's not correct to say that it
hasn't been implemented yet; folks aren't waiting for the browsers.
The differing behaviors in the null-or-undefined case should probably be
remedied, a
Again, the reasoning at the time was that `Promise.all(x)` could be
considered sugar for `Promise.resolve(x).all()` in ES7, and so
`Promise.all` was "really" an instance method after all. Again, I could
support a change, I'm just saying it wasn't totally crazy, and no one made
any objection at the
(Sorry, that should have been `Promise.resolve`, not `Promise#resolve`.)
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Without rehashing the previous discussion, I totally disagree. Having
`Promise#resolve()` go through `@@species` made it totally useless. It's
also not in the spirit of the smalltalk species, which used very narrowly
for instance methods like `map`, not for constructors.
--scott
___
As referenced in the cited thread
(https://esdiscuss.org/topic/performpromiseall#content-6) there are
actually two uses of the Promise constructor in the definition of
`all` and `race`. To quote myself:
> [N]ote that the implementations given for `Promise.all` and `Promise.race`
> use Promises i
IMO promises should reject if they are "cancelled". The same method that
gave you the Promise (for example, an AJAX API) can give you a capability
to "cancel" the Promise, ie cancel the pending network operation and reject
the Promise (rejecting is a no-op if the operation races with cancellation
up
float".
--scott
On Wed, Aug 26, 2015 at 12:01 PM, Martin von Gagern
wrote:
> Hello Scott,
>
> Thanks for the comment!
>
> On 26.08.2015 17:22, C. Scott Ananian wrote:
> > `fesetround` would be a terrible way for JavaScript to implement this,
>
> I agree, the
`fesetround` would be a terrible way for JavaScript to implement this, as
it would allow a piece of code to affect the behavior of completely
unrelated pieces of code by screwing with global rounding mode bits.
That's not going to happen.
I believe there have been proposals to allow greater access
And --- apologies for continuing to beat this drum --- you can look at the
`prfun` package on npm for a practical example of this use of Promise
subclasses and `resolve`.
If other folks know of other libraries using these features, let me know so
I can recommend other people's code as well as my o
outside
> the process. Basically, we take the ECMAScript regular expression object as
> specified (minus allowing extensions) as our base line :)
>
>
> Cheers,
> Benji
>
>
> On Mon, Jul 6, 2015 at 5:03 PM, C. Scott Ananian
> wrote:
>>
>> I think it would
I think it would be more worthwhile of we tried to draw a compatibility
boundary. Taking perlre as a baseline, for example, are there additional
characters we should escape in `RegExp.escape` so that implementations (and
the language itself) could add more perlre features without breaking
compatib
You can get `Promise #finally` by using a helper library, like `prfun`.
But the finally method in particular has a quirk, see the end of:
https://github.com/cscott/prfun/blob/master/README.md#promisefinallyfunction-handler--promise
It would be nice to resolve that properly before standardization.
On Wed, Jul 1, 2015 at 9:22 AM, Alex Kocharin wrote:
> People regularly suggest borrowing concepts from different languages here
> (we got arrow functions from coffee, generators are from python I believe).
>
And `@@species` is from smalltalk. (More or less.)
Lots of smalltalk influence, actu
But the design might work well as a proxy object? It could delegate
to the "real" object, with its private slots, after that object is
created.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Jun 30, 2015 at 3:46 AM, Benjamin Gruenbaum
wrote:
> I'm still not sure if it's worth it, after all it's just sugar for
> `RegExp.escape(str).replace(/[a-z]/gu, m => `\\${m}`)`
>
I think you're making my point! And I hope your version of `RegExp.escape`
doesn't use hexadecimal or unicod
And I'm suggesting that `RegExp.escape(str, /[image: ☺]/ug)` is a much
better idea.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Please, not an iterable over characters. (Or at least, "not only".) Use a
RegExp. Imagine trying to ensure that any characters over \u007f were
escaped. You don't want an iterable over ~64k characters.
In addition, a RegExp would allow you to concisely specify "hex digits, but
only at the start
It's not too surprising: it's the same reason why the ES6 spec was just
published *on paper*, with the html version being explicitly flagged as
non-normative.
For standards work, having a reliable substrate is important. It is not
the TC's job to innovate on or experiment with collaboration platf
I think you will note that many of the "built in" methods in the spec are
already implemented in JavaScript code in many implementations (v8,
firefox). Similarly the ability to implement more fundamental features in
terms of macro definitions may well be pursued by the implementations. But
note
No, thank you.
Email clients are the ultimate forum aggregators.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
An interesting wrinkle in language design has been the rise of
sophisticated linting and style tools like `jscs`. If you wish to
deprecate `var` for instance, it is straightforward to write a jscs module
to enforce that. Further, several large communities (node, wikipedia, etc)
have published jsc
It seem semi-obligatory at this point to cite "Growing a Language", by Guy
Steele.
https://www.youtube.com/watch?v=_ahvzDzKdB0
Transcript at http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
(if you must).
I tend to agree with the idea that at this point we need *means to grow
syntax* ra
Filed Pull Requests to es6-shim and core-js to match the late change to the
`Promise.reject` text.
Yay final spec!
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Could you include some examples of *calling* functions defined this way?
The most obvious way uses `Function#call` and would be terribly awkward.
Perhaps I'm just overlooking some ES6 feature which makes passing a
specific `this` value easy?
It seems curious that you are not using methods instead
To throw some more paint on the bikeshed:
The "instanceof RegExp" and "RegExp(...)" parts of the "perfect"
implementation of `RegExp.tag` should also be fixed to play nicely with
species.
I think Allen and I would say that you should *not* use the species pattern
for instantiating the new regexp
On Sat, Jun 13, 2015 at 1:51 AM, Mark S. Miller wrote:
> Nice! Inspired
>
> // Based on
> // https://github.com/benjamingr/RexExp.escape/blob/master/polyfill.js
> function re(template, ...subs) {
> const parts = [];
> const numSubs = subs.length;
> for (let i = 0; i < numSubs; i
@Alexander Jones: no new syntax is needed to implement what you want; we
already have Template Strings. For example, you could define a new
function `RegExp.join` (which takes either an array or a string as its
first argument, see below):
```
var pattern = RegExp.join`^(abc${ "someString, escaped
On Wed, Jun 10, 2015 at 11:46 AM, Domenic Denicola wrote:
> Regardless of whether or not you agree, that was the original motivation
> for its introduction.
>
https://twitter.com/awbjs/status/535962895532584960 says:
> ES6 final tweaks #8: Smalltalk-like species pattern used in Array methods,
I don't agree that @@species is useful at all for changing constructor
signatures, since there is no closure argument.
If we had dynamically scoped variables, then:
```
LabelledPromise[Symbol.species] = function() { return
LabelledPromise.bind(label/*dynamically scoped*/); };
function() {
@Domenic: please see the previous discussion at
https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50
since there is much more discussion back-and-forth there.
And you are correct about Promise.reject; Allen is proposing to remove the
@@species from that method as well.
T
On Wed, Jun 10, 2015 at 10:37 AM, Allen Wirfs-Brock
wrote:
> However, I think that Promise.reject should parallel Promise.resolve and
> hence it should not use species.
>
I agree.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mai
On Tue, Jun 9, 2015 at 3:45 PM, Mark Miller wrote:
> I don't understand your answer. p and r are plain promises. They must be
> because they exist before q does. q is the first remote promise in this
> scenario. How does resolving r to q leave r unsettled but give q access to
> the messages buffe
On Tue, Jun 9, 2015 at 1:43 PM, Mark S. Miller wrote:
> On Tue, Jun 9, 2015 at 10:38 AM, C. Scott Ananian
> wrote:
>
>> I think that Promise pipelining works just fine -- you just have to
>> implement it inside Promise#get, Promise#put, etc.
>> ```
>> // This i
> rej(v) );
}
}
```
--scott
On Tue, Jun 9, 2015 at 12:56 PM, Mark S. Miller wrote:
>
>
> On Tue, Jun 9, 2015 at 9:35 AM, C. Scott Ananian
> wrote:
>
>> Promise subclassing is super useful. `prfun` uses it extensively: first
>> to override the global `Promise` to
On Tue, Jun 9, 2015 at 12:38 PM, Mark S. Miller wrote:
> Do you ever test that the object returned by `Promise#timeout(n)` is
> something other than a plain promise?
>
Responded on the other thread.
Let's keep this one focused on: do we need to tweak the definitions of
`Promise.all` and `Promis
On Tue, Jun 9, 2015 at 12:38 PM, Mark S. Miller wrote:
> On Tue, Jun 9, 2015 at 9:29 AM, C. Scott Ananian
> wrote:
>
>> Mark: The `prfun` library in fact uses `Promise#timeout(n)` instead of a
>> `TimeoutPromise` subclass. But this is really a language-design question.
Promise subclassing is super useful. `prfun` uses it extensively: first to
override the global `Promise` to avoid polluting the global namespace, and
then secondly to implement features like `Promise#bind`. I've also used it
experimentally to implement "functional" promises (with a `Promise#chain
Mark: The `prfun` library in fact uses `Promise#timeout(n)` instead of a
`TimeoutPromise` subclass. But this is really a language-design question.
You might as well ask why we have `WeakMap()` as a constructor instead of
using `Map#weak()` or `weakmapify(map)`. The fundamental reason is "so you
c
On Tue, Jun 9, 2015 at 11:11 AM, Mark S. Miller wrote:
> Ok, thanks for the example. I understand your rationale. This is what I
> asked for but not what I was really looking for. Can we come up with an
> example where class and species usefully differ where neither is Promise?
> IOW, where the s
Mark: I outlined two of these use cases in
https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50
One is `WeakPromise` which is a promise holding a weak reference to its
resolved value. This is the closest analogy with the canonical Smalltalk
motivating example for species
`Promise.resolve` doesn't use the species pattern any more:
https://esdiscuss.org/topic/fixing-promise-resolve
The rationale was that `resolve` is more like a constructor than a mutator.
I don't have a strong opinion about `Promise.all`, but I think perhaps it
would be better if none of the static
Thanks! It looks like core-js has already patched in the new spec:
https://github.com/zloirock/core-js/issues/75
I've opened https://github.com/paulmillr/es6-shim/issues/344 on es6-shim,
and I'll see if I can get a patch together for it.
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=11
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.the
On Tue, May 19, 2015 at 12:24 PM, Steve Fink wrote:
> That visually collides with destructuring for me.
>
> let [a, b] = foo();
> let {a, b} = foo();
> let f(a, b) = foo(); # Very different
>
> I almost expect that last one to use f as a custom matcher of some sort,
> given the previous two.
We
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-w
On Thu, Apr 30, 2015 at 5:57 PM, Jordan Harband wrote:
> I don't see how it would be possible in ES6 user code to ever make a
> Map/Set or a Map/Set subclass instance immutable, since
> `Map.prototype.set.call`/`Set.prototype.add.call` will operate on any
> Map/Set-like object's `[[MapData]]`/`[[
I like the idea of snapshot methods, but they can be implemented in user
code using subclasses in ES6. I'm particularly interested in the "lock
down in place" mechanism because it *cannot* be implemented in user code.
And yes, if we had it all to do over again, it would have been nice if the
Map
o Map. If you subclass it, freeze it,
override set/delete/etc it is still possible to mutate the map using
`Map.set.call(m, 'a', 'b');`. And there is no way for use code to get at
the [[MapData]] slot to protect it.
--scott
On Thu, Apr 30, 2015 at 2:42 PM, C. Scott Anan
On Thu, Apr 30, 2015 at 2:22 PM, Mark S. Miller wrote:
> It would also not be compatible with ES6 code. SES will be freezing Map,
> Set, WeakMap, and WeakSet instances in order to tamper proof their API. I
> expect many others will as well. Having this freeze then cause a
> non-mutability in ES7
f the collections.
>
> I welcome proposals that would make sense for JavaScript.
>
>
>
> On Thu, Apr 30, 2015 at 9:52 AM, C. Scott Ananian
> wrote:
>
>> On Mon, Feb 23, 2015 at 3:31 PM, Mark S. Miller
>> wrote:
>>
>>> On Mon, Feb 23, 2015 at 11:
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 Mon, Feb 23, 2015 at 3:31 PM, Mark S. Miller wrote:
> On Mon, Feb 23, 2015 at 11:59 AM, Isiah Meadows
> wrote:
>>
>> On Feb 23, 2015 6:06 AM, "Andrea Giammarchi"
>> wrote:
>>
>> > On Sun, Feb 22, 2015 at 11:18 PM, Jordan Harband
>> wrote:
>>
> [...]
>
>> >> - We'd definitely want `Map.empt
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, 2
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) {
>>
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
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
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 rea
On Wed, Apr 29, 2015 at 12:56 PM, Allen Wirfs-Brock
wrote:
> On Apr 29, 2015, at 9:04 AM, C. Scott Ananian wrote:
> > I suppose it would be nice if JavaScript engines fell back to passing
> arguments on the heap to avoid this problem, but I don't think that's part
&g
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?
Aren't there limits to the number of arguments you can pass to a ES
function before getting a stack overflow?
I've gotten in trouble trying to abuse the `arguments` array like this
before, for example `Math.max.apply(Math, someVeryLargeArray)`.
Empirically, with iojs 1.8.1:
```
> Math.max.apply(M
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
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 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
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
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 `Objec
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 perfo
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
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);
```
On Tue, Dec 16, 2014 at 4:15 PM, Kevin Smith wrote:
>
> We cannot tell with just two tokens of lookahead whether we need to parse
> a concise method or a function declaration.
>
[...]
> Otherwise, are there any other parsing tricks which might help out? (I'm
> not 100% sure what our constraints
On Thu, Dec 4, 2014 at 9:25 AM, Katelyn Gadd wrote:
> The only way I can imagine to solve
> this is to make really aggressive use of type information gathering
> and/or bailouts in the runtime to identify every type used as a
> weakmap key - at which point I suppose you would have to convert thei
On Wed, Nov 12, 2014 at 12:15 PM, James Long wrote:
> On Wed, Nov 12, 2014 at 12:11 PM, Jussi Kalliokoski
> wrote:
>> Actually that already works, at least in Chrome, if you execute
>>
>> (function () {
>> return new Promise(function (resolve, reject) {
>> reject(new Error("foo"));
>> });
On Wed, Nov 12, 2014 at 11:08 AM, Axel Rauschmayer wrote:
> Is that true, though? Couldn’t a finalizer or something similar check
> (before a promise is garbage collected) whether all errors have been
> handled?
A finalizer can do this check. This will flag some uncaught
exceptions, but not prom
I think you're missing the point: you need to solve the halting problem if
you expect to get prompt notification of asynchronous exceptions. This
can't be solved at a language level. The only solution is to expose the
pending unhandled exceptions to programmers so that they can use their
human jud
1 - 100 of 258 matches
Mail list logo