search

domenic / promises-unwrapping

The ES6 promises spec, as per September 2013 TC39 meeting
1.24k stars 95 forks source link

Switch to memoizing the result of assimilation #2

Closed domenic closed 11 years ago

domenic commented 11 years ago

This would be what implementations do anyway, and it will be observable once we introduce thenables.

domenic commented 11 years ago

Since it's actually impossible to construct a chain of promises-for-promises right now, with only pure-promises and only resolve, it doesn't make sense to do this before #3, which would be the only way to introduce chains (via badly-behaved thenables).

domenic commented 11 years ago

That is, there is currently no way to introduce a p such that p.[[Following]].[[Following]] is set.

domenic commented 11 years ago

As noted by @kriskowal in #8, we should also maintain a side-table of assimilated thenables so that a thenable's then is never triggered more than once no matter how many promises assimilate it. A WeakMap should work nicely, implementation-wise, since it holds neither keys nor values strongly.

domenic commented 11 years ago

OK, this turned out to be easier than I imagined. I went down a few dead ends, trying to memoize by re-setting .[[Value]]s to be whatever ended up at the end of the thenable chain, but that didn't even work for certain cases, as some tests I wrote showed. You end up needing a weak map anyway, and it turns out just introducing that in the right place solves all problems right away.

Let me know what you think. This is the last major change in the underlying mechanics, I believe; the rest is just gravy (e.g. the static combinators).