On Mon, Aug 26, 2013 at 7:47 AM, Mark Miller wrote:
> If we do call the coercer Promise.from, as should rename the acceptor
> Promise.accept rather than Promise.of. If we want an Array coercer rather
> than an Array copier, we should consider renaming Array.from to Array.as.
I oppose naming the "
The existing Array.from also copies the array-like, even if it is an array.
Clearly such a copying operation is useful. Whether this should be bundled
into Array.from, and whether .from is the right name if it is, are valid
questions.
However, my first reaction is, leave Array.from alone. It is no
What do we think of having "from" be the coercer? By which I mean, change
Array.from to return its input if given a true Array (or properly-subclassed
one with [[ArrayInitialisationState]] set to true, maybe??). Then Promise.from
could follow that semantic, returning the input if it's a true pro
Kevin Smith wrote:
I don't think you'll want to have divergent behavior for construct vs.
call with new APIs. I believe that would go against Allen's approach
for new ES6 built in classes, and beyond that, it unnecessarily
overloads the API surface. Different operations ought to have
differe
I don't think you'll want to have divergent behavior for construct vs. call
with new APIs. I believe that would go against Allen's approach for new
ES6 built in classes, and beyond that, it unnecessarily overloads the API
surface. Different operations ought to have different names.
{ Kevin }
___
On Thu, Aug 22, 2013 at 9:24 AM, Mark S. Miller wrote:
>> Use whatever method you feel like for
>> determining that you were called as a constructor.
>
> What test to use for this determination was the entire question!
Not really - that was only important *if* passing the test meant we
used the `
On Thu, Aug 22, 2013 at 9:22 AM, Brandon Benvie wrote:
> On 8/22/2013 8:04 AM, Mark S. Miller wrote:
>
>> var Promise = (function(){
>> "use strict"; // of course
>>
>> var brand = new WeakMap();
>>
>> // only ever called with "new"
>> function HiddenPromiseCon
On 8/22/2013 8:04 AM, Mark S. Miller wrote:
var Promise = (function(){
"use strict"; // of course
var brand = new WeakMap();
// only ever called with "new"
function HiddenPromiseConstructor(callback) {
// initialize "this", which it can assume sta
On Thu, Aug 22, 2013 at 9:13 AM, Tab Atkins Jr. wrote:
> On Thu, Aug 22, 2013 at 8:04 AM, Mark S. Miller
> wrote:
> > You're right, my code is wrong. What I meant is:
> >
> > Object.create(p, {Promise: {value: Promise}}).Promise()
> >
> > In other words, the Promise constructor might ge
On Thu, Aug 22, 2013 at 8:04 AM, Mark S. Miller wrote:
> You're right, my code is wrong. What I meant is:
>
> Object.create(p, {Promise: {value: Promise}}).Promise()
>
> In other words, the Promise constructor might get supplied as its "this" an
> object that passes "p instanceof Promise
On Thu, Aug 22, 2013 at 8:04 AM, Mark S. Miller wrote:
> On Wed, Aug 21, 2013 at 10:22 PM, Tab Atkins Jr. wrote:
>
>> On Wed, Aug 21, 2013 at 5:55 PM, Mark S. Miller
>> wrote:
>> > On Wed, Aug 21, 2013 at 5:33 PM, Tab Atkins Jr.
>> > wrote:
>> >>
>> >> On Wed, Aug 21, 2013 at 5:12 PM, Mark S. M
On Wed, Aug 21, 2013 at 10:22 PM, Tab Atkins Jr. wrote:
> On Wed, Aug 21, 2013 at 5:55 PM, Mark S. Miller
> wrote:
> > On Wed, Aug 21, 2013 at 5:33 PM, Tab Atkins Jr.
> > wrote:
> >>
> >> On Wed, Aug 21, 2013 at 5:12 PM, Mark S. Miller
> >> wrote:
> >>> On Wed, Aug 21, 2013 at 3:44 PM, Tab Atki
On Wed, Aug 21, 2013 at 5:55 PM, Mark S. Miller wrote:
> On Wed, Aug 21, 2013 at 5:33 PM, Tab Atkins Jr.
> wrote:
>>
>> On Wed, Aug 21, 2013 at 5:12 PM, Mark S. Miller
>> wrote:
>>> On Wed, Aug 21, 2013 at 3:44 PM, Tab Atkins Jr.
>>> wrote:
But I like just Promise(), sans "new".
>>>
>>> Go
Correction to meta-summary. We got to this state of happy agreement by
purposely postponing two issues:
a) We encapsulated the question of "what is a thenable?" into an abstract
isThenable(v) function which we have postponed defining.
b) We have postponed pinning down what happens if one attempts
First, yes, relying of ES5 + WeakMap is fine, since we have a reliable and
secure (though painful and leaky) WeakMap polyfill for ES5. However, even
with that, how do you construct a function which can distinguish whether it
is called with "new" or not?
On Wed, Aug 21, 2013 at 7:15 PM, Tab Atkins
On Wed, Aug 21, 2013 at 7:13 PM, Domenic Denicola
wrote:
> From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
>
>> Unless you wanted promise-likes to return fresh objects too?
>
> Yes, that is largely the use case for `Q`/`Promise.as`/whatever. Handing it
> untrusted input, possible a non-promise
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
> Unless you wanted promise-likes to return fresh objects too?
Yes, that is largely the use case for `Q`/`Promise.as`/whatever. Handing it
untrusted input, possible a non-promise, possibly a promise-like, possibly a
promise, and getting back a
On Wed, Aug 21, 2013 at 5:55 PM, Mark S. Miller wrote:
> On Wed, Aug 21, 2013 at 5:33 PM, Tab Atkins Jr.
> wrote:
>>
>> On Wed, Aug 21, 2013 at 5:12 PM, Mark S. Miller
>> wrote:
>> > On Wed, Aug 21, 2013 at 3:44 PM, Tab Atkins Jr.
>> > wrote:
>> >>
>> >> On Wed, Aug 21, 2013 at 3:36 PM, Domenic
I am generally against sacrificing things for polyfillability. I'd rather say
"if you're using this polyfill and need security guarantees, use `Promise.as`
(or `Q`, even); if you want forward-compatibility at the expense of security,
use `Promise`."
Other options could involve using the module
On Wed, Aug 21, 2013 at 6:04 PM, Tab Atkins Jr. wrote:
> On Wed, Aug 21, 2013 at 6:00 PM, Brendan Eich wrote:
> > Mark S. Miller wrote:
> >>
> >>
> >> Cool. That means we get a decent naming precedent for the monad
> ops,
> >> and consistency with Array.of (which also happens to be a mon
On Wed, Aug 21, 2013 at 6:00 PM, Brendan Eich wrote:
> Mark S. Miller wrote:
>>
>>
>> Cool. That means we get a decent naming precedent for the monad ops,
>> and consistency with Array.of (which also happens to be a monadic
>> lifter, if you limit yourself to calling it with only a si
Meta summary: AFAICT, Tab and I are in 100% agreement on all issues either
of us has raised!
An non-meta summary will take more time ;).
On Wed, Aug 21, 2013 at 6:00 PM, Brendan Eich wrote:
> Mark S. Miller wrote:
>
>>
>> Cool. That means we get a decent naming precedent for the monad ops
Mark S. Miller wrote:
Cool. That means we get a decent naming precedent for the monad ops,
and consistency with Array.of (which also happens to be a monadic
lifter, if you limit yourself to calling it with only a single
argument).
I agree that this naming analogy is a good thi
On Wed, Aug 21, 2013 at 5:33 PM, Tab Atkins Jr. wrote:
> On Wed, Aug 21, 2013 at 5:12 PM, Mark S. Miller
> wrote:
> > On Wed, Aug 21, 2013 at 3:44 PM, Tab Atkins Jr.
> > wrote:
> >>
> >> On Wed, Aug 21, 2013 at 3:36 PM, Domenic Denicola
> >> wrote:
> >> > On Aug 21, 2013, at 18:31, "Mark S. Mil
On Wed, Aug 21, 2013 at 5:12 PM, Mark S. Miller wrote:
> On Wed, Aug 21, 2013 at 3:44 PM, Tab Atkins Jr.
> wrote:
>>
>> On Wed, Aug 21, 2013 at 3:36 PM, Domenic Denicola
>> wrote:
>> > On Aug 21, 2013, at 18:31, "Mark S. Miller" wrote:
>> >> Good idea. As a coercing function, a natural name is
On Wed, Aug 21, 2013 at 3:44 PM, Tab Atkins Jr. wrote:
> On Wed, Aug 21, 2013 at 3:36 PM, Domenic Denicola
> wrote:
> > On Aug 21, 2013, at 18:31, "Mark S. Miller" wrote:
> >> Good idea. As a coercing function, a natural name is Promise.as(v1).
> Also,
> >> as a common coercer, brevity is a virt
On Wed, Aug 21, 2013 at 3:36 PM, Domenic Denicola
wrote:
> On Aug 21, 2013, at 18:31, "Mark S. Miller" wrote:
>> Good idea. As a coercing function, a natural name is Promise.as(v1). Also,
>> as a common coercer, brevity is a virtue.
>
> How about just `Promise`, following `String`, `Number`, `Reg
How about just `Promise`, following `String`, `Number`, `RegExp`, etc.?
(I tend to agree with Tab that both #a and #b should return a new promise. But
we do need an easy coercion function, as Mark emphasizes.)
On Aug 21, 2013, at 18:31, "Mark S. Miller"
mailto:erig...@google.com>> wrote:
On
On Wed, Aug 21, 2013 at 3:16 PM, Tab Atkins Jr. wrote:
> On Wed, Aug 21, 2013 at 1:57 PM, Mark S. Miller
> wrote:
> > Excellent excellent! It seems we are in agreement and clarity on all
> > terminology issue, and on almost complete agreement on substantive
> issues.
> > The only remaining issue
On Wed, Aug 21, 2013 at 1:57 PM, Mark S. Miller wrote:
> Excellent excellent! It seems we are in agreement and clarity on all
> terminology issue, and on almost complete agreement on substantive issues.
> The only remaining issue is whether either of the following expressions
> always return a fre
Excellent excellent! It seems we are in agreement and clarity on all
terminology issue, and on almost complete agreement on substantive issues.
The only remaining issue is whether either of the following expressions
always return a fresh promise, and if they are exactly equivalent:
a) Promise.reso
On Tue, Aug 20, 2013 at 8:55 PM, Mark S. Miller wrote:
> On Tue, Aug 20, 2013 at 11:04 AM, Tab Atkins Jr.
> wrote:
>> Argh, I knew this would turn into another confusing terminology
>> discussion. ^_^
>
> Indeed ;).
>
> I think this is because you more naturally think at the AP2.flatMap level of
On Tue, Aug 20, 2013 at 8:55 PM, Mark S. Miller wrote:
> On Tue, Aug 20, 2013 at 11:04 AM, Tab Atkins Jr. wrote:
>
>> On Tue, Aug 20, 2013 at 9:18 AM, Mark S. Miller
>> wrote:
>> > To answer this precisely, we need good terminology to distinguish two
>> levels
>> > of abstraction: The distinctio
On Tue, Aug 20, 2013 at 11:04 AM, Tab Atkins Jr. wrote:
> On Tue, Aug 20, 2013 at 9:18 AM, Mark S. Miller
> wrote:
> > To answer this precisely, we need good terminology to distinguish two
> levels
> > of abstraction: The distinctions observable to the AP2.flatMap programmer
> > and the coarser d
On Tue, Aug 20, 2013 at 9:18 AM, Mark S. Miller wrote:
> To answer this precisely, we need good terminology to distinguish two levels
> of abstraction: The distinctions observable to the AP2.flatMap programmer
> and the coarser distinctions observable to the AP2.then programmer. Let's
> start igno
On Tue, Aug 20, 2013 at 9:18 AM, Mark S. Miller wrote:
> On Tue, Aug 20, 2013 at 8:32 AM, Tab Atkins Jr. wrote:
>
>> On Tue, Aug 20, 2013 at 7:08 AM, Mark S. Miller
>> wrote:
>> > Hi Anne, Thanks for the reminder. My message of last night fell into
>> that
>> > same old trap (ignoring the storag
On Tue, Aug 20, 2013 at 9:18 AM, Mark S. Miller wrote:
> On Tue, Aug 20, 2013 at 8:32 AM, Tab Atkins Jr. wrote:
>
>> On Tue, Aug 20, 2013 at 7:08 AM, Mark S. Miller
>> wrote:
>> > Hi Anne, Thanks for the reminder. My message of last night fell into
>> that
>> > same old trap (ignoring the storag
On Tue, Aug 20, 2013 at 8:32 AM, Tab Atkins Jr. wrote:
> On Tue, Aug 20, 2013 at 7:08 AM, Mark S. Miller
> wrote:
> > Hi Anne, Thanks for the reminder. My message of last night fell into that
> > same old trap (ignoring the storage cost) and that previous reversal of
> mine
> > is still mostly co
On Tue, Aug 20, 2013 at 7:08 AM, Mark S. Miller wrote:
> Hi Anne, Thanks for the reminder. My message of last night fell into that
> same old trap (ignoring the storage cost) and that previous reversal of mine
> is still mostly correct, However, the missing operation is not .fulfill for
> the reas
From: annevankeste...@gmail.com
> In particular, what *kind* of unwrapping does then() do on the input and
> return side (ideally expressed in pseudo-code).
I believe this comes down to the as-yet-unresolved conversation about thenable
assimilation vs. branding and such. In any case, it should
Indeed, nice catch Anne. I guess it's an unfortunate necessity that the monadic
stuff will need to drag along two methods, not just one.
A name like "unit" (or perhaps "of") seems to fit better in my mind, than
introducing another natural-language verb like "accept." Especially since it
will be
On Tue, Aug 20, 2013 at 3:08 PM, Mark S. Miller wrote:
> Hi Anne, Thanks for the reminder. My message of last night fell into that
> same old trap (ignoring the storage cost) and that previous reversal of mine
> is still mostly correct, However, the missing operation is not .fulfill for
> the reas
Hi Anne, Thanks for the reminder. My message of last night fell into that
same old trap (ignoring the storage cost) and that previous reversal of
mine is still mostly correct, However, the missing operation is not
.fulfill for the reasons Domenic correctly explains. It is .accept
(possibly named .o
On Tue, Aug 20, 2013 at 2:48 AM, Mark S. Miller wrote:
> I agree that an AP2 system, which is what we are discussing, should not have
> a method named .fulfill for the reasons you state. A promise which, at the
> AP2.flatMap level is "accepted" or "adopted" is, at the AP2.then level
> "resolved".
> The "earlier" you are talking about, IIUC, is the monadic promise variant.
>
I don't like using the term "monadic" because it sounds pointy-headed : )
> Monads are fine things, and a monadic promise=like abstraction would
> probably be useful for some things. However, it is a very different
>
How does what you mean by .then here differ from .flatMap? If it is the
same, why not rename your .then to .flatMap and rename your .when to .then ?
On Mon, Aug 19, 2013 at 8:14 PM, Kevin Smith wrote:
> Implementation:
>
> function unwrap(value) {
> return Promise.resolve(value).the
Hi Kevin, I misinterpreted you. By "earlier", I thought you were referring
to the promise APIs in actual use which are compatible with Promises/A+.
These do not create promises-for-promises (auto-flattening or auto-lifting
depending on how you want to think about it) and they recursively unwrap
the
Implementation:
function unwrap(value) {
return Promise.resolve(value).then(v => isPromise(v) ? unwrap(v) :
v);
}
Promise.when = value => unwrap(value);
Test:
var promise = new Promise(r => {
r.fulfill(new Promise(r => { r.fulfill(1); }));
});
promise.th
Thanks Mark.
To clarify my overly brief interjection, I tend to favor the conceptual
simplicity of the earlier "DOM" API. Specifically:
- no "flatMap"
- the output of then is single-unwrapped
- no recursive unwrapping
I find it more simple from a conceptual standpoint because each promise
simpl
I agree that an AP2 system, which is what we are discussing, should not
have a method named .fulfill for the reasons you state. A promise which, at
the AP2.flatMap level is "accepted" or "adopted" is, at the AP2.then level
"resolved". I suggest the method in question be called .resolve, that it
acc
Mark, I completely agree with you. However, I think this somewhat ignores the
issue of this thread. The problem with AP2, even completely ignoring `flatMap`,
comes when you consider the behavior of the `Promise.fulfill` method. Namely,
what does this code do?
```js
var foreverPending = new Prom
On Mon, Aug 19, 2013 at 6:20 PM, Mark S. Miller wrote:
> Let's separate two forms of complexity:
>
> a) Complexity visible to those who must use, implement, or understand the
> full API including .flatMap.
>
> b) Complexity visible to those who only use, implement, or understand the
> subset with
Let's separate two forms of complexity:
a) Complexity visible to those who must use, implement, or understand the
full API including .flatMap.
b) Complexity visible to those who only use, implement, or understand the
subset without .flatMap.
The main beauty of AP2 is that it minimizes the comple
> With all the changes to Promise (addition of Promise#flatMap, recursive
> unwrap on input side of Promise#then, etc.), it does seem that fulfill's
> use case has become a bit muddled. I'll admit to still being partial to the
> earlier design (fulfill/resolve/reject, adopt without recursive
> unwr
On Mon, Aug 19, 2013 at 11:13 AM, Domenic Denicola
wrote:
> Tab and I think the solution to this is to:
>
> - Kill `Promise.fulfill`, and of course also the `fulfill` option to the
> promise initializer.
> - Change `flatMap` to operate on resolved values, so that
> `Promise.resolve(foreverPendin
On Mon, Aug 19, 2013 at 12:50 PM, Ron Buckton wrote:
> Promise.fulfill/PromiseSource#fulfill made sense when there was no unwrap on
> the input side of Promise#then:
Exactly.
> With all the changes to Promise (addition of Promise#flatMap, recursive
> unwrap on input side of Promise#then, etc.)
re straightforward API.
Ron
> -Original Message-
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Domenic Denicola
> Sent: Monday, August 19, 2013 11:13 AM
> To: es-discuss@mozilla.org
> Subject: Killing `Promise.fulfill`
>
> In https://mail.mozi
I don't really understand your response. What timeouts are you talking about?
(Wrong thread perhaps?)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
So what? This isn't bad. It's just what happens in implementations where
you don't have timeouts enforced by the system.
C'est la vie.
On Monday, August 19, 2013, Domenic Denicola wrote:
> In https://mail.mozilla.org/pipermail/es-discuss/2013-August/032724.html(plus
> following errata) I create
In https://mail.mozilla.org/pipermail/es-discuss/2013-August/032724.html (plus
following errata) I created the following promise:
```js
var foreverPending = new Promise(() => {});
var acceptedButNotResolved = Promise.fulfill(foreverPending);
```
This brings up the horrible point that `Promise.fu
60 matches
Mail list logo
