I know last few attempts to unify promise API did not got us anywhere, but I still would like to give it another try, because I believe that having no consensus is partially a reason for a low adoption of promises in the js community. My suggestion would be reducing promises API to bare minimum, which would allow both approaches (then-able promises / q) to be build on top. Interoperability on a base level will allow us to move forward without reinventing same wheel with a different flavors and everyone will benefit from that.
I'm still fairly new to promises and please bare with me if I miss something important. I wrote [this proposal](https://gist.github.com/711766) which I believe allows us to implement both of the proposed APIs as layer on top or as set of utilities without compromising important points on both camps.
I can also provide implementation snippets if necessary on how then or when can be implemented on top.
On Tue, Nov 23, 2010 at 14:48, Irakli Gozalishvili <rfo...@gmail.com> wrote: > Hi,
> I know last few attempts to unify promise API did not got us anywhere, but > I still would like to give it another try, because I believe that having no > consensus is partially a reason for a low adoption of promises in the js > community. My > suggestion would be reducing promises API to bare minimum, which would > allow both approaches (then-able promises / q) to be build on top. > Interoperability on a base level will allow us to move forward without > reinventing same wheel with a different flavors and everyone will benefit > from that.
> I'm still fairly new to promises and please bare with me if I miss > something important. I wrote [this proposal]( > https://gist.github.com/711766) which I believe allows us to implement > both of the proposed APIs as layer > on top or as set of utilities without compromising important points on both > camps.
> I can also provide implementation snippets if necessary on how then or when > can be implemented on top.
> I know last few attempts to unify promise API did not got us anywhere, > but I still would like to give it another try, because I believe that > having no consensus is partially a reason for a low adoption of > promises in the js community. My > suggestion would be reducing promises API to bare minimum, which would > allow both approaches (then-able promises / q) to be build on top. > Interoperability on a base level will allow us to move forward without > reinventing same wheel with a different flavors and everyone will > benefit from that.
http://wiki.commonjs.org/wiki/Promises/A has a single required method. I don't follow what you are reducing if you create a new proposal that 3 or 4 methods/constructors. Promises/A is the bare minimum (unless you think we can specify promises with less than 1 construct ;) ), and Promises/B can already be implemented on it except for the opaque promise clause.
> I'm still fairly new to promises and please bare with me if I miss > something important. I wrote [this > proposal](https://gist.github.com/711766) which I believe allows us to > implement both of the proposed APIs as layer > on top or as set of utilities without compromising important points on > both camps.
The only incompatibility between Promises/A and /B is that /B explicitly forbids compatibility with /A (the opaque promise clause). I don't know you achieve interoperability with a specification that forbids interoperability! Modulo this clause, I believe /A and /B are already easily unifiable (/B can readily be built on /A), in fact I think the promise module from promised-io more or less implements /A and /B right now.
On Tue, Nov 23, 2010 at 7:49 AM, Kris Zyp <kris...@gmail.com> wrote: > http://wiki.commonjs.org/wiki/Promises/A has a single required method. I > don't follow what you are reducing if you create a new proposal that 3 > or 4 methods/constructors. Promises/A is the bare minimum (unless you > think we can specify promises with less than 1 construct ;) ), and > Promises/B can already be implemented on it except for the opaque > promise clause.
I agree with Kris* that this proposal does less to unify and more to separate two already nearly compatible proposals.
I'm also still adamant that Promises/A is simpler but too simple and that Promise/B must be the base. It's stricter (which is good in my opinion) and quite simple.
It seems more likely to me that this issue can only be resolved in two ways:
1.) Kris* and I switch places for a month and use and develop on each other's respective systems and come back with nice things to say about each other's ideas.
2.) Elect an arbiter from the small collection of people who have used both systems and agree, for the purpose of CommonJS, to abide their judgement as to which proposal gets eliminated and which gets pursued. As far as I know, Irakli and Nathan Stott are the only two candidates.
The trouble with 2 is that I, at this point, would not be willing to discontinue my work on Promises/B stuff regardless of what gets adopted by CommonJS (which is unfortunate but not critical for progress), and the trouble with 1 is that I don't have a whole lot of time. (For context, I have given myself a couple months to work on my pet projects before I consider getting a real job. One of these projects is built on Promises/B.)
So maybe, Kris* and I need to have a peace summit or something.
One concession I can definitely give: If people use the Promises/B API (which has been implemented for Promises/A successfully), Nathan has verified that such code will work when using a Promises/A implementation. However, code written for Promises/A does not necessarily work on a Promises/B implementation. It is possible within Promises/B for the opaque promise object to actually be a Promises/A thenable (if you don't use Q.get, Q.put, Q.post, &c) IF users construct thenables exclusively with the Q API. There are disadvantages to this approach (thenable promises can be confused with thenable values, without being able to exercise the advantages of thenables), but you could get by in most cases.
It remains clear to me that Promises/B is the firmer ground for a specification and Promises/A is better left as an option for implementors.
> > I know last few attempts to unify promise API did not got us anywhere, > > but I still would like to give it another try, because I believe that > > having no consensus is partially a reason for a low adoption of > > promises in the js community. My > > suggestion would be reducing promises API to bare minimum, which would > > allow both approaches (then-able promises / q) to be build on top. > > Interoperability on a base level will allow us to move forward without > > reinventing same wheel with a different flavors and everyone will > > benefit from that.
> http://wiki.commonjs.org/wiki/Promises/A has a single required method. I > don't follow what you are reducing if you create a new proposal that 3 > or 4 methods/constructors. Promises/A is the bare minimum (unless you > think we can specify promises with less than 1 construct ;) ),
From my view Promises/A just omits many things that needs to be specified but that is less important then note below:
> and > Promises/B can already be implemented on it except for the opaque > promise clause.
Yes that exactly why we do have two camps. I also do agree with KrisK that **opaque** is must have.
> > I'm still fairly new to promises and please bare with me if I miss > > something important. I wrote [this > > proposal](https://gist.github.com/711766) which I believe allows us to > > implement both of the proposed APIs as layer > > on top or as set of utilities without compromising important points on > > both camps.
> The only incompatibility between Promises/A and /B is that /B explicitly > forbids compatibility with /A (the opaque promise clause). I don't know > you achieve interoperability with a specification that forbids > interoperability!
I thin you are misunderstanding the point that was made on the opaque promise clause. Yes it's true that building opaque promise on top of non-opaque is impossible, while it's pretty much possible other way round. That's more or less what I'm suggesting.
I don't know if you sew my naive implementation examples, but what I'm suggesting to have much more minimalistic opaque promise that can easily be extended to a thenable. Also if Q API will be build on top promises produced by both libraries would be able to talk with each other.
Modulo this clause, I believe /A and /B are already
> easily unifiable (/B can readily be built on /A), in fact I think the > promise module from promised-io more or less implements /A and /B right > now.
opaque clause is only reason why we have two camps today and ignoring this clause really won't get us anywhere. Is there any reason why you don't want to build thenable promises on top of opaque ones ?
> -- > You received this message because you are subscribed to the Google Groups > "CommonJS" group. > To post to this group, send email to commonjs@googlegroups.com. > To unsubscribe from this group, send email to > commonjs+unsubscribe@googlegroups.com<commonjs%2Bunsubscribe@googlegroups.c om> > . > For more options, visit this group at > http://groups.google.com/group/commonjs?hl=en.
> > I know last few attempts to unify promise API did not got us > anywhere, > > but I still would like to give it another try, because I believe > that > > having no consensus is partially a reason for a low adoption of > > promises in the js community. My > > suggestion would be reducing promises API to bare minimum, which > would > > allow both approaches (then-able promises / q) to be build on top. > > Interoperability on a base level will allow us to move forward > without > > reinventing same wheel with a different flavors and everyone will > > benefit from that.
> http://wiki.commonjs.org/wiki/Promises/A has a single required > method. I > don't follow what you are reducing if you create a new proposal that 3 > or 4 methods/constructors. Promises/A is the bare minimum (unless you > think we can specify promises with less than 1 construct ;) ),
> From my view Promises/A just omits many things that needs to be > specified but that is less important then note below:
> and > Promises/B can already be implemented on it except for the opaque > promise clause.
> Yes that exactly why we do have two camps. I also do agree with KrisK > that **opaque** is must have.
> > I'm still fairly new to promises and please bare with me if I miss > > something important. I wrote [this > > proposal](https://gist.github.com/711766) which I believe allows > us to > > implement both of the proposed APIs as layer > > on top or as set of utilities without compromising important > points on > > both camps.
> The only incompatibility between Promises/A and /B is that /B > explicitly > forbids compatibility with /A (the opaque promise clause). I don't > know > you achieve interoperability with a specification that forbids > interoperability!
> I thin you are misunderstanding the point that was made on the opaque > promise clause. Yes it's true that building opaque promise on top of > non-opaque is impossible, while it's pretty much possible other way > round. That's more or less what I'm suggesting.
Opaque and non-opaque are opposite, you can't build one on top of the other, regardless of the order.
> I don't know if you sew my naive implementation examples, but what I'm > suggesting to have much more minimalistic opaque promise that can > easily be extended to a thenable. Also if Q API will be build on top > promises produced by both libraries would be able to talk with each other.
You have thenable, but it isn't the Q promise, you now have two different promise forms, you done nothing to unify them.
> Modulo this clause, I believe /A and /B are already > easily unifiable (/B can readily be built on /A), in fact I think the > promise module from promised-io more or less implements /A and /B > right now.
> opaque clause is only reason why we have two camps today and ignoring > this clause really won't get us anywhere. Is there any reason why you > don't want to build thenable promises on top of opaque ones ?
On Tue, Nov 23, 2010 at 18:35, Kris Kowal <kris.ko...@cixar.com> wrote: > On Tue, Nov 23, 2010 at 7:49 AM, Kris Zyp <kris...@gmail.com> wrote: > > http://wiki.commonjs.org/wiki/Promises/A has a single required method. I > > don't follow what you are reducing if you create a new proposal that 3 > > or 4 methods/constructors. Promises/A is the bare minimum (unless you > > think we can specify promises with less than 1 construct ;) ), and > > Promises/B can already be implemented on it except for the opaque > > promise clause.
> I agree with Kris* that this proposal does less to unify and more to > separate two already nearly compatible proposals.
> I'm also still adamant that Promises/A is simpler but too simple and > that Promise/B must be the base. It's stricter (which is good in my > opinion) and quite simple.
> It seems more likely to me that this issue can only be resolved in two > ways:
> 1.) Kris* and I switch places for a month and use and develop on each > other's respective systems and come back with nice things to say about > each other's ideas.
> 2.) Elect an arbiter from the small collection of people who have used > both systems and agree, for the purpose of CommonJS, to abide their > judgement as to which proposal gets eliminated and which gets pursued. > As far as I know, Irakli and Nathan Stott are the only two candidates.
I don't think either one or another is going to work out. People will continue to use whatever they prefer, at least I will. My main attention was to suggest common ground to make promises interchangeable.
> The trouble with 2 is that I, at this point, would not be willing to > discontinue my work on Promises/B stuff regardless of what gets > adopted by CommonJS (which is unfortunate but not critical for > progress), and the trouble with 1 is that I don't have a whole lot of > time. (For context, I have given myself a couple months to work on my > pet projects before I consider getting a real job. One of these > projects is built on Promises/B.)
> So maybe, Kris* and I need to have a peace summit or something.
> One concession I can definitely give: If people use the Promises/B API > (which has been implemented for Promises/A successfully), Nathan has > verified that such code will work when using a Promises/A > implementation. However, code written for Promises/A does not > necessarily work on a Promises/B implementation. It is possible within > Promises/B for the opaque promise object to actually be a Promises/A > thenable (if you don't use Q.get, Q.put, Q.post, &c) IF users > construct thenables exclusively with the Q API. There are > disadvantages to this approach (thenable promises can be confused with > thenable values, without being able to exercise the advantages of > thenables), but you could get by in most cases.
> It remains clear to me that Promises/B is the firmer ground for a > specification and Promises/A is better left as an option for > implementors.
> Kris**
> -- > You received this message because you are subscribed to the Google Groups > "CommonJS" group. > To post to this group, send email to commonjs@googlegroups.com. > To unsubscribe from this group, send email to > commonjs+unsubscribe@googlegroups.com<commonjs%2Bunsubscribe@googlegroups.c om> > . > For more options, visit this group at > http://groups.google.com/group/commonjs?hl=en.
>> > I know last few attempts to unify promise API did not got us anywhere, >> > but I still would like to give it another try, because I believe that >> > having no consensus is partially a reason for a low adoption of >> > promises in the js community. My >> > suggestion would be reducing promises API to bare minimum, which would >> > allow both approaches (then-able promises / q) to be build on top. >> > Interoperability on a base level will allow us to move forward without >> > reinventing same wheel with a different flavors and everyone will >> > benefit from that.
>> http://wiki.commonjs.org/wiki/Promises/A has a single required method. I >> don't follow what you are reducing if you create a new proposal that 3 >> or 4 methods/constructors. Promises/A is the bare minimum (unless you >> think we can specify promises with less than 1 construct ;) ),
> From my view Promises/A just omits many things that needs to be specified > but that is less important then note below:
>> and >> Promises/B can already be implemented on it except for the opaque >> promise clause.
> Yes that exactly why we do have two camps. I also do agree with KrisK that > **opaque** is must have.
When issue I have with opaque promises is how they could be made to work in a sandboxed environment? Wouldn't you have to do some magic like injecting the promise lib as part of the environment and catching any require("promise") calls to satisfy the instanceof check? Is there any cleaner way?
I would imagine *securable *trumps *opaque*, right?
>> > I know last few attempts to unify promise API did not got us anywhere, >> > but I still would like to give it another try, because I believe that >> > having no consensus is partially a reason for a low adoption of >> > promises in the js community. My >> > suggestion would be reducing promises API to bare minimum, which would >> > allow both approaches (then-able promises / q) to be build on top. >> > Interoperability on a base level will allow us to move forward without >> > reinventing same wheel with a different flavors and everyone will >> > benefit from that.
>> http://wiki.commonjs.org/wiki/Promises/A has a single required method. I >> don't follow what you are reducing if you create a new proposal that 3 >> or 4 methods/constructors. Promises/A is the bare minimum (unless you >> think we can specify promises with less than 1 construct ;) ),
> From my view Promises/A just omits many things that needs to be specified > but that is less important then note below:
>> and >> Promises/B can already be implemented on it except for the opaque >> promise clause.
> Yes that exactly why we do have two camps. I also do agree with KrisK that > **opaque** is must have.
>> > I'm still fairly new to promises and please bare with me if I miss >> > something important. I wrote [this >> > proposal](https://gist.github.com/711766) which I believe allows us to >> > implement both of the proposed APIs as layer >> > on top or as set of utilities without compromising important points on >> > both camps.
>> The only incompatibility between Promises/A and /B is that /B explicitly >> forbids compatibility with /A (the opaque promise clause). I don't know >> you achieve interoperability with a specification that forbids >> interoperability!
> I thin you are misunderstanding the point that was made on the opaque > promise clause. Yes it's true that building opaque promise on top of > non-opaque is impossible, while it's pretty much possible other way round. > That's more or less what I'm suggesting.
> Opaque and non-opaque are opposite, you can't build one on top of the > other, regardless of the order.
> I don't know if you sew my naive implementation examples, but what I'm > suggesting to have much more minimalistic opaque promise that can easily be > extended to a thenable. Also if Q API will be build on top promises produced > by both libraries would be able to talk with each other.
> You have thenable, but it isn't the Q promise, you now have two different > promise forms, you done nothing to unify them.
Both of them are layers on top of (promise/c) if you like and while indeed B and A are not unified by this, this would our libraries to talk with each others which is not the case at the moment.
> Modulo this clause, I believe /A and /B are already >> easily unifiable (/B can readily be built on /A), in fact I think the >> promise module from promised-io more or less implements /A and /B right >> now.
> opaque clause is only reason why we have two camps today and ignoring this > clause really won't get us anywhere. Is there any reason why you don't want > to build thenable promises on top of opaque ones ?
On Tue, Nov 23, 2010 at 9:44 AM, Kris Zyp <kris...@gmail.com> wrote: > Opaque and non-opaque are opposite, you can't build one on top of the other, > regardless of the order.
That's certainly not the intent of the opacity clause. It is meant to say that the consumer of the Q API cannot depend any further implementation details of the returned promises, e.g., thenability. They are opaque in the sense that the consumer cannot see behind them. You certainly can build Promises/B on top of Promises/A for the purpose of Q.when. The specification addresses use, not construction.
I will chime in more later when I have more time to compose my thoughts.
Right now this is an important issue to me as Bogart is built on of Zyp promises but I want to use Jaque in my projects as well which is built on Kowal promises.
It was my impression, until I actually tried it, that as long as I avoided using '.then' and only used 'Q.when' that the promise implementation wouldn't matter. This is not the case. I wish it were and some way to get us to that point would be most welcome.
On Tue, Nov 23, 2010 at 12:01 PM, Kris Kowal <kris.ko...@cixar.com> wrote: > On Tue, Nov 23, 2010 at 9:44 AM, Kris Zyp <kris...@gmail.com> wrote: >> Opaque and non-opaque are opposite, you can't build one on top of the other, >> regardless of the order.
> That's certainly not the intent of the opacity clause. It is meant to > say that the consumer of the Q API cannot depend any further > implementation details of the returned promises, e.g., thenability. > They are opaque in the sense that the consumer cannot see behind them. > You certainly can build Promises/B on top of Promises/A for the > purpose of Q.when. The specification addresses use, not construction.
> Does this change anything for you?
> Kris Kowal
> -- > You received this message because you are subscribed to the Google Groups "CommonJS" group. > To post to this group, send email to commonjs@googlegroups.com. > To unsubscribe from this group, send email to commonjs+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
On Tue, Nov 23, 2010 at 9:45 AM, Dean Landolt <d...@deanlandolt.com> wrote: > When issue I have with opaque promises is how they could be made to work in > a sandboxed environment? Wouldn't you have to do some magic like injecting > the promise lib as part of the environment and catching any > require("promise") calls to satisfy the instanceof check? Is there any > cleaner way?
That would indeed be necessary for promises to communicate between the sandbox and the parent. Promise/B is designed with the intent that promise objects be frozen in such situations too, so that promises designated to multiple mutually suspicious sandboxes can safely communicate unidirectionally.
> I would imagine securable trumps opaque, right?
Unless the purpose of opacity is to satisfy security. It is not safe to use the thenable API directly because doing so gives the receipient excess authority: multiple resolution, multiple rejection, same-turn resolution, and same-turn rejection.
On Tue, Nov 23, 2010 at 1:05 PM, Kris Kowal <kris.ko...@cixar.com> wrote: > On Tue, Nov 23, 2010 at 9:45 AM, Dean Landolt <d...@deanlandolt.com> > wrote: > > When issue I have with opaque promises is how they could be made to work > in > > a sandboxed environment? Wouldn't you have to do some magic like > injecting > > the promise lib as part of the environment and catching any > > require("promise") calls to satisfy the instanceof check? Is there any > > cleaner way?
> That would indeed be necessary for promises to communicate between the > sandbox and the parent. Promise/B is designed with the intent that > promise objects be frozen in such situations too, so that promises > designated to multiple mutually suspicious sandboxes can safely > communicate unidirectionally.
> > I would imagine securable trumps opaque, right?
> Unless the purpose of opacity is to satisfy security. It is not safe > to use the thenable API directly because doing so gives the receipient > excess authority: multiple resolution, multiple rejection, same-turn > resolution, and same-turn rejection.
The `then` is but a registrar, identical to `Q.when` in every way but where it is carried. How could `then` expose resolution or rejection? I was under the impression that it cannot.
On Tue, Nov 23, 2010 at 11:40 AM, Dean Landolt <d...@deanlandolt.com> wrote: > The `then` is but a registrar, identical to `Q.when` in every way but where > it is carried. How could `then` expose resolution or rejection? I was under > the impression that it cannot.
In object capabilities, the "promise.then(resolved, rejected)" function "introduces" the "promise" to your "resolved" and "rejected" capabilities. That means that the recipient, "promise", can now call those functions, "exercise those capabilities", at any time from the point of invocation. That's why the "Q.when" method in Tyler Close's original code and my derivative "protects" the "resolved" and "rejected" by wrapping them in a new, trustworthy promise that guarantees that the resolved and rejected functions can only be called once, either one or the other, in a future turn of the event loop.
On Tue, Nov 23, 2010 at 11:45 AM, Kris Kowal <kris.ko...@cixar.com> wrote: > In object capabilities, the "promise.then(resolved, rejected)" > function "introduces" the "promise" to your "resolved" and "rejected" > capabilities. That means that the recipient, "promise", can now call > those functions, "exercise those capabilities", at any time from the > point of invocation. That's why the "Q.when" method in Tyler Close's > original code and my derivative "protects" the "resolved" and > "rejected" by wrapping them in a new, trustworthy promise that > guarantees that the resolved and rejected functions can only be called > once, either one or the other, in a future turn of the event loop.
These invariants are important not only for security, but for safety and robust composition. The Q API is much more resilient against laziness and error than the then API which it conceptually builds on top of.
On Tue, Nov 23, 2010 at 1:04 PM, Nathan Stott <nrst...@gmail.com> wrote: > I will chime in more later when I have more time to compose my thoughts.
> Right now this is an important issue to me as Bogart is built on of > Zyp promises but I want to use Jaque in my projects as well which is > built on Kowal promises.
> It was my impression, until I actually tried it, that as long as I > avoided using '.then' and only used 'Q.when' that the promise > implementation wouldn't matter. This is not the case. I wish it > were and some way to get us to that point would be most welcome.
In my experience the issue of interop is most complicated by the difficulties of the top-level namespace. As far as Promises/B goes, when you require("promise") (or require("q") or whatever) you better be sure you're getting the same promise lib as cooperating libraries.
So interop should be feasible -- we just have to be sure we can all get a handle on the same Promise object so we can make the instanceof tests work. It's possible that the Kris Zyp implementation could try to extend require("q").Promise to satisfy the instanceof check.
On Tue, Nov 23, 2010 at 2:47 PM, Kris Kowal <kris.ko...@cixar.com> wrote: > On Tue, Nov 23, 2010 at 11:45 AM, Kris Kowal <kris.ko...@cixar.com> wrote: > > In object capabilities, the "promise.then(resolved, rejected)" > > function "introduces" the "promise" to your "resolved" and "rejected" > > capabilities. That means that the recipient, "promise", can now call > > those functions, "exercise those capabilities", at any time from the > > point of invocation. That's why the "Q.when" method in Tyler Close's > > original code and my derivative "protects" the "resolved" and > > "rejected" by wrapping them in a new, trustworthy promise that > > guarantees that the resolved and rejected functions can only be called > > once, either one or the other, in a future turn of the event loop.
Thanks for the explanation. This helps me understand a little better the opaqueness requirement -- the only rationale that I was aware of before was collision prevention, which doesn't really stand on its own.
Still, how do you propose we solve the namespace problem? Have we made any progress on this? Can we *really* trust require("promise") will be available on all platforms? Should we standardize on a commonjs prefix a la require("commonjs/promise")? Without a solution to this problem how could Promises/B really be used interoperably?
> These invariants are important not only for security, but for safety > and robust composition. The Q API is much more resilient against > laziness and error than the then API which it conceptually builds on > top of.
Interesting -- I've found the biggest safety hazard has been synchronous throws -- and neither promise lib can really do much to rectify this. It's just a wart of the API itself that could only be fixed with something like a Q.whenCall (Kris Zyp's suggestion some time ago). Any thoughts on this?
While I do like Kris Kowal's Q implementation and use it for all my promise needs today, I think that promise spec can and should be more minimal. I made an attempt to do so, obviously it may not look amazing but I believe it can be shaped to an acceptable state. That being said I tried to address few important points:
1. It satisfies opaque clause (I won't go into details on why is it important, Kris did it already) 2. Both Q and then chain-able promises can be built on top which will make them interoperable. 3. To my knowledge streaming is not well expressed by Q, IMO then-ables are better with that, there for my proposal suggests a way to express steams in opaque promise. 4. I've started work on ES Harmony Proxy based promises, then-able promises is no go there for obvious reasons, Q-is better, but 1. It comes with lot's of stuff that is useless with Proxy based promises. 2. 'emit' method on promise objects get's in the way. This is also addressed by suggested proposal.
I really don't want to come up with yet another promise implementation that will be incompatible and will lead to even bigger fragmentation. All needed is just a minimal spec that can address all the points mentioned. I don't care whether it will be promise a/b/c or d as long all of this is addressed.
I really hope you will consider this points and we'll find a ways to move forward. In the and we all wish to have much broader adoption of promises.
On Tue, Nov 23, 2010 at 21:05, Dean Landolt <d...@deanlandolt.com> wrote:
> On Tue, Nov 23, 2010 at 1:04 PM, Nathan Stott <nrst...@gmail.com> wrote:
>> I will chime in more later when I have more time to compose my thoughts.
>> Right now this is an important issue to me as Bogart is built on of >> Zyp promises but I want to use Jaque in my projects as well which is >> built on Kowal promises.
>> It was my impression, until I actually tried it, that as long as I >> avoided using '.then' and only used 'Q.when' that the promise >> implementation wouldn't matter. This is not the case. I wish it >> were and some way to get us to that point would be most welcome.
> In my experience the issue of interop is most complicated by the > difficulties of the top-level namespace. As far as Promises/B goes, when you > require("promise") (or require("q") or whatever) you better be sure you're > getting the same promise lib as cooperating libraries.
> So interop should be feasible -- we just have to be sure we can all get a > handle on the same Promise object so we can make the instanceof tests work. > It's possible that the Kris Zyp implementation could try to extend > require("q").Promise to satisfy the instanceof check.
> -- > You received this message because you are subscribed to the Google Groups > "CommonJS" group. > To post to this group, send email to commonjs@googlegroups.com. > To unsubscribe from this group, send email to > commonjs+unsubscribe@googlegroups.com<commonjs%2Bunsubscribe@googlegroups.c om> > . > For more options, visit this group at > http://groups.google.com/group/commonjs?hl=en.
> On Tue, Nov 23, 2010 at 9:44 AM, Kris Zyp <kris...@gmail.com> wrote: >> Opaque and non-opaque are opposite, you can't build one on top of the other, >> regardless of the order. > That's certainly not the intent of the opacity clause. It is meant to > say that the consumer of the Q API cannot depend any further > implementation details of the returned promises, e.g., thenability. > They are opaque in the sense that the consumer cannot see behind them. > You certainly can build Promises/B on top of Promises/A for the > purpose of Q.when. The specification addresses use, not construction.
> Does this change anything for you?
If you can't depend on then(), you can't build interoperable promise promise producers and consumers can you? You're still stuck needing to have a single authoritative source of promises, right? And what is a non-opaque opaque promise then?
> While I do like Kris Kowal's Q implementation and use it for all my promise > needs today, I think that promise spec can and should be more minimal. I > made an attempt to do so, obviously it may not look amazing but I believe it > can be shaped to an acceptable state. That being said I tried to address few > important points:
> 1. It satisfies opaque clause (I won't go into details on why is it > important, Kris did it already) > 2. Both Q and then chain-able promises can be built on top which will make > them interoperable. > 3. To my knowledge streaming is not well expressed by Q, IMO then-ables are > better with that, there for my proposal suggests a way to express steams in > opaque promise.
While I'm not 100% sure exactly what kind of streams you're referring to here I think this exposes a fundamental miscommunication. The functionality exposed by the signatures of each are equivalent in every way but one: `when` can handle non-promise (typed) values as well as promises. Thus, it is a superset of `then`. AFAIC the chainability of the `then` method is nothing more than a neat side-effect of the need to have a method key to specify on -- you can't rely on it with untrusted inputs and I can't see how it actually adds anything to make it more amenable to streams.
> 4. I've started work on ES Harmony Proxy based promises, then-able promises > is no go there for obvious reasons, Q-is better, but 1. It comes with lot's > of stuff that is useless with Proxy based promises. 2. 'emit' method on > promise objects get's in the way. This is also addressed by suggested > proposal.
> I really don't want to come up with yet another promise implementation that > will be incompatible and will lead to even bigger fragmentation. All needed > is just a minimal spec that can address all the points mentioned. I don't > care whether it will be promise a/b/c or d as long all of this is addressed.
I'm with you there. But AFAICT it's both better and worse than you think. A and B are almost identical -- interoperable in every way -- but the opaqueness constraint is a fundamental incompatibility. Promises/A solves interop nicely but at the cost of opacity. Promises/B is arguably more correct but requires you to use The One True Promise Library. Oh, and you have to make sure your code gets the same One True Promise Library as the libraries you're exchanging promises with. To date this is an unsolved problem.
> I really hope you will consider this points and we'll find a ways to move > forward. In the and we all wish to have much > broader adoption of promises.
> On Tue, Nov 23, 2010 at 21:05, Dean Landolt <d...@deanlandolt.com> wrote:
>> On Tue, Nov 23, 2010 at 1:04 PM, Nathan Stott <nrst...@gmail.com> wrote:
>>> I will chime in more later when I have more time to compose my thoughts.
>>> Right now this is an important issue to me as Bogart is built on of >>> Zyp promises but I want to use Jaque in my projects as well which is >>> built on Kowal promises.
>>> It was my impression, until I actually tried it, that as long as I >>> avoided using '.then' and only used 'Q.when' that the promise >>> implementation wouldn't matter. This is not the case. I wish it >>> were and some way to get us to that point would be most welcome.
>> In my experience the issue of interop is most complicated by the >> difficulties of the top-level namespace. As far as Promises/B goes, when you >> require("promise") (or require("q") or whatever) you better be sure you're >> getting the same promise lib as cooperating libraries.
>> So interop should be feasible -- we just have to be sure we can all get a >> handle on the same Promise object so we can make the instanceof tests work. >> It's possible that the Kris Zyp implementation could try to extend >> require("q").Promise to satisfy the instanceof check.
>> -- >> You received this message because you are subscribed to the Google Groups >> "CommonJS" group. >> To post to this group, send email to commonjs@googlegroups.com. >> To unsubscribe from this group, send email to >> commonjs+unsubscribe@googlegroups.com<commonjs%2Bunsubscribe@googlegroups.c om> >> . >> For more options, visit this group at >> http://groups.google.com/group/commonjs?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "CommonJS" group. > To post to this group, send email to commonjs@googlegroups.com. > To unsubscribe from this group, send email to > commonjs+unsubscribe@googlegroups.com<commonjs%2Bunsubscribe@googlegroups.c om> > . > For more options, visit this group at > http://groups.google.com/group/commonjs?hl=en.
On Tue, Nov 23, 2010 at 22:01, Dean Landolt <d...@deanlandolt.com> wrote:
> On Tue, Nov 23, 2010 at 3:34 PM, Irakli Gozalishvili <rfo...@gmail.com>wrote:
>> Let me add few more arguments to my proposal:
>> While I do like Kris Kowal's Q implementation and use it for all my >> promise needs today, I think that promise spec can and should be more >> minimal. I made an attempt to do so, obviously it may not look amazing but I >> believe it can be shaped to an acceptable state. That being said I tried to >> address few important points:
>> 1. It satisfies opaque clause (I won't go into details on why is it >> important, Kris did it already) >> 2. Both Q and then chain-able promises can be built on top which will make >> them interoperable. >> 3. To my knowledge streaming is not well expressed by Q, IMO then-ables >> are better with that, there for my proposal suggests a way to express steams >> in opaque promise.
> While I'm not 100% sure exactly what kind of streams you're referring to > here I think this exposes a fundamental miscommunication. The functionality > exposed by the signatures of each are equivalent in every way but one: > `when` can handle non-promise (typed) values as well as promises. Thus, it > is a superset of `then`. AFAIC the chainability of the `then` method is > nothing more than a neat side-effect of the need to have a method key to > specify on -- you can't rely on it with untrusted inputs and I can't see how > it actually adds anything to make it more amenable to streams.
In Q if I'm not miss-lead promise transitions from one state to another and nothing like progress notifications exist. KrisZ had forEach-able promises and then also accepts 3rd onProgress listener that may be called for each delivered chunk.
>> 4. I've started work on ES Harmony Proxy based promises, then-able >> promises is no go there for obvious reasons, Q-is better, but 1. It comes >> with lot's of stuff that is useless with Proxy based promises. 2. 'emit' >> method on promise objects get's in the way. This is also addressed by >> suggested proposal.
>> I really don't want to come up with yet another promise implementation >> that will be incompatible and will lead to even bigger fragmentation. All >> needed is just a minimal spec that can address all the points mentioned. I >> don't care whether it will be promise a/b/c or d as long all of this is >> addressed.
> I'm with you there. But AFAICT it's both better and worse than you think. A > and B are almost identical -- interoperable in every way -- but the > opaqueness constraint is a fundamental incompatibility. Promises/A solves > interop nicely but at the cost of opacity. Promises/B is arguably more > correct but requires you to use The One True Promise Library. Oh, and you > have to make sure your code gets the same One True Promise Library as the > libraries you're exchanging promises with. To date this is an unsolved > problem.
Well there is fundamental difference in way promises are chained, mainly because of opacity. Unless Promise/A will respect that clause no interoperability will be possible.
>> I really hope you will consider this points and we'll find a ways to move >> forward. In the and we all wish to have much >> broader adoption of promises.
>> On Tue, Nov 23, 2010 at 21:05, Dean Landolt <d...@deanlandolt.com> wrote:
>>> On Tue, Nov 23, 2010 at 1:04 PM, Nathan Stott <nrst...@gmail.com> wrote:
>>>> I will chime in more later when I have more time to compose my thoughts.
>>>> Right now this is an important issue to me as Bogart is built on of >>>> Zyp promises but I want to use Jaque in my projects as well which is >>>> built on Kowal promises.
>>>> It was my impression, until I actually tried it, that as long as I >>>> avoided using '.then' and only used 'Q.when' that the promise >>>> implementation wouldn't matter. This is not the case. I wish it >>>> were and some way to get us to that point would be most welcome.
>>> In my experience the issue of interop is most complicated by the >>> difficulties of the top-level namespace. As far as Promises/B goes, when you >>> require("promise") (or require("q") or whatever) you better be sure you're >>> getting the same promise lib as cooperating libraries.
>>> So interop should be feasible -- we just have to be sure we can all get a >>> handle on the same Promise object so we can make the instanceof tests work. >>> It's possible that the Kris Zyp implementation could try to extend >>> require("q").Promise to satisfy the instanceof check.
>>> -- >>> You received this message because you are subscribed to the Google Groups >>> "CommonJS" group. >>> To post to this group, send email to commonjs@googlegroups.com. >>> To unsubscribe from this group, send email to >>> commonjs+unsubscribe@googlegroups.com<commonjs%2Bunsubscribe@googlegroups.c om> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/commonjs?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "CommonJS" group. >> To post to this group, send email to commonjs@googlegroups.com. >> To unsubscribe from this group, send email to >> commonjs+unsubscribe@googlegroups.com<commonjs%2Bunsubscribe@googlegroups.c om> >> . >> For more options, visit this group at >> http://groups.google.com/group/commonjs?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "CommonJS" group. > To post to this group, send email to commonjs@googlegroups.com. > To unsubscribe from this group, send email to > commonjs+unsubscribe@googlegroups.com<commonjs%2Bunsubscribe@googlegroups.c om> > . > For more options, visit this group at > http://groups.google.com/group/commonjs?hl=en.
On Tue, Nov 23, 2010 at 21:43, Kris Zyp <kris...@gmail.com> wrote:
> On 11/23/2010 11:01 AM, Kris Kowal wrote: > > On Tue, Nov 23, 2010 at 9:44 AM, Kris Zyp <kris...@gmail.com> wrote: > >> Opaque and non-opaque are opposite, you can't build one on top of the > other, > >> regardless of the order. > > That's certainly not the intent of the opacity clause. It is meant to > > say that the consumer of the Q API cannot depend any further > > implementation details of the returned promises, e.g., thenability. > > They are opaque in the sense that the consumer cannot see behind them. > > You certainly can build Promises/B on top of Promises/A for the > > purpose of Q.when. The specification addresses use, not construction.
> > Does this change anything for you?
> If you can't depend on then(), you can't build interoperable promise > promise producers and consumers can you? You're still stuck needing to > have a single authoritative source of promises, right? And what is a > non-opaque opaque promise then?
Yes you can, that exactly what proposal was about. It just defines authority that can issue promises and defines the way promise state can be identified. All types of chaining can be build on top. Promises have to be issued by one module and all the libs: Q, then-able and whoever else will, be able to define issuers that just issues core promises with their own API's layer on top. All this libraries will be able to ignore layers added by other libs. Sorry I'm not native speaker and I might not be explaining it well enough, but I believe examples here illustrate that pretty well:
> -- > You received this message because you are subscribed to the Google Groups > "CommonJS" group. > To post to this group, send email to commonjs@googlegroups.com. > To unsubscribe from this group, send email to > commonjs+unsubscribe@googlegroups.com<commonjs%2Bunsubscribe@googlegroups.c om> > . > For more options, visit this group at > http://groups.google.com/group/commonjs?hl=en.
> On Tue, Nov 23, 2010 at 22:01, Dean Landolt <d...@deanlandolt.com> wrote:
>> On Tue, Nov 23, 2010 at 3:34 PM, Irakli Gozalishvili <rfo...@gmail.com>wrote:
>>> Let me add few more arguments to my proposal:
>>> While I do like Kris Kowal's Q implementation and use it for all my >>> promise needs today, I think that promise spec can and should be more >>> minimal. I made an attempt to do so, obviously it may not look amazing but I >>> believe it can be shaped to an acceptable state. That being said I tried to >>> address few important points:
>>> 1. It satisfies opaque clause (I won't go into details on why is it >>> important, Kris did it already) >>> 2. Both Q and then chain-able promises can be built on top which will >>> make them interoperable. >>> 3. To my knowledge streaming is not well expressed by Q, IMO then-ables >>> are better with that, there for my proposal suggests a way to express steams >>> in opaque promise.
>> While I'm not 100% sure exactly what kind of streams you're referring to >> here I think this exposes a fundamental miscommunication. The functionality >> exposed by the signatures of each are equivalent in every way but one: >> `when` can handle non-promise (typed) values as well as promises. Thus, it >> is a superset of `then`. AFAIC the chainability of the `then` method is >> nothing more than a neat side-effect of the need to have a method key to >> specify on -- you can't rely on it with untrusted inputs and I can't see how >> it actually adds anything to make it more amenable to streams.
> In Q if I'm not miss-lead promise transitions from one state to another and > nothing like progress notifications exist. KrisZ had forEach-able promises > and then also accepts 3rd onProgress listener that may be called for each > delivered chunk.
>>> 4. I've started work on ES Harmony Proxy based promises, then-able >>> promises is no go there for obvious reasons, Q-is better, but 1. It comes >>> with lot's of stuff that is useless with Proxy based promises. 2. 'emit' >>> method on promise objects get's in the way. This is also addressed by >>> suggested proposal.
>>> I really don't want to come up with yet another promise implementation >>> that will be incompatible and will lead to even bigger fragmentation. All >>> needed is just a minimal spec that can address all the points mentioned. I >>> don't care whether it will be promise a/b/c or d as long all of this is >>> addressed.
>> I'm with you there. But AFAICT it's both better and worse than you think. >> A and B are almost identical -- interoperable in every way -- but the >> opaqueness constraint is a fundamental incompatibility. Promises/A solves >> interop nicely but at the cost of opacity. Promises/B is arguably more >> correct but requires you to use The One True Promise Library. Oh, and you >> have to make sure your code gets the same One True Promise Library as the >> libraries you're exchanging promises with. To date this is an unsolved >> problem.
> Well there is fundamental difference in way promises are chained, mainly > because of opacity. Unless Promise/A will respect that clause no > interoperability will be possible.
Yes, I know -- I was trying to point out that the APIs themselves are completely compatible but was making the point about opacity. That said, a Promise/A implementation could extend the One True Promise constructor to be interoperable with a Promise/B implementation. But this does absolutely nothing for my uneasiness about this assumption that require("promise") will always give you the right library. There's nothing in SecurableModules that can give you this guarantee. This isn't just an academic concern: the possibility of this or any promise implementation ending up in node approaches 0. So you've got to path shift. Unless we come up with something better dependency hell for opaque promises is virtually assured.
On Wed, Nov 24, 2010 at 00:15, Dean Landolt <d...@deanlandolt.com> wrote:
> On Tue, Nov 23, 2010 at 4:42 PM, Irakli Gozalishvili <rfo...@gmail.com>wrote:
>> On Tue, Nov 23, 2010 at 22:01, Dean Landolt <d...@deanlandolt.com> wrote:
>>> On Tue, Nov 23, 2010 at 3:34 PM, Irakli Gozalishvili <rfo...@gmail.com>wrote:
>>>> Let me add few more arguments to my proposal:
>>>> While I do like Kris Kowal's Q implementation and use it for all my >>>> promise needs today, I think that promise spec can and should be more >>>> minimal. I made an attempt to do so, obviously it may not look amazing but I >>>> believe it can be shaped to an acceptable state. That being said I tried to >>>> address few important points:
>>>> 1. It satisfies opaque clause (I won't go into details on why is it >>>> important, Kris did it already) >>>> 2. Both Q and then chain-able promises can be built on top which will >>>> make them interoperable. >>>> 3. To my knowledge streaming is not well expressed by Q, IMO then-ables >>>> are better with that, there for my proposal suggests a way to express steams >>>> in opaque promise.
>>> While I'm not 100% sure exactly what kind of streams you're referring to >>> here I think this exposes a fundamental miscommunication. The functionality >>> exposed by the signatures of each are equivalent in every way but one: >>> `when` can handle non-promise (typed) values as well as promises. Thus, it >>> is a superset of `then`. AFAIC the chainability of the `then` method is >>> nothing more than a neat side-effect of the need to have a method key to >>> specify on -- you can't rely on it with untrusted inputs and I can't see how >>> it actually adds anything to make it more amenable to streams.
>> In Q if I'm not miss-lead promise transitions from one state to another >> and nothing like progress notifications exist. KrisZ had forEach-able >> promises and then also accepts 3rd onProgress listener that may be called >> for each delivered chunk.
>>>> 4. I've started work on ES Harmony Proxy based promises, then-able >>>> promises is no go there for obvious reasons, Q-is better, but 1. It comes >>>> with lot's of stuff that is useless with Proxy based promises. 2. 'emit' >>>> method on promise objects get's in the way. This is also addressed by >>>> suggested proposal.
>>>> I really don't want to come up with yet another promise implementation >>>> that will be incompatible and will lead to even bigger fragmentation. All >>>> needed is just a minimal spec that can address all the points mentioned. I >>>> don't care whether it will be promise a/b/c or d as long all of this is >>>> addressed.
>>> I'm with you there. But AFAICT it's both better and worse than you think. >>> A and B are almost identical -- interoperable in every way -- but the >>> opaqueness constraint is a fundamental incompatibility. Promises/A solves >>> interop nicely but at the cost of opacity. Promises/B is arguably more >>> correct but requires you to use The One True Promise Library. Oh, and you >>> have to make sure your code gets the same One True Promise Library as the >>> libraries you're exchanging promises with. To date this is an unsolved >>> problem.
>> Well there is fundamental difference in way promises are chained, mainly >> because of opacity. Unless Promise/A will respect that clause no >> interoperability will be possible.
> Yes, I know -- I was trying to point out that the APIs themselves are > completely compatible but was making the point about opacity. That said, a > Promise/A implementation could extend the One True Promise constructor to be > interoperable with a Promise/B implementation. But this does absolutely > nothing for my uneasiness about this assumption that require("promise") will > always give you the right library. There's nothing in SecurableModules that > can give you this guarantee. This isn't just an academic concern: the > possibility of this or any promise implementation ending up in node > approaches 0. So you've got to path shift. Unless we come up with something > better dependency hell for opaque promises is virtually assured.
Ok I see! I think that most of the nodejs community is on npm that sort of guarantees that require('promise') will return the same thing or throw regardless of combination of packages installed. Also here can be something like require('commonjs/promise') that will provide base promise API that will be used behind the scenes by both require('q') and require('promise') to construct promises.
-- You received this message because you are subscribed to the Google Groups "CommonJS" group. To post to this group, send email to commonjs@googlegroups.com. To unsubscribe from this group, send email to commonjs+unsubscribe@googlegroups.com<commonjs%2Bunsubscribe@googlegroups.c om> . For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
> On Wed, Nov 24, 2010 at 00:15, Dean Landolt <d...@deanlandolt.com> wrote:
>> On Tue, Nov 23, 2010 at 4:42 PM, Irakli Gozalishvili <rfo...@gmail.com>wrote:
>>> On Tue, Nov 23, 2010 at 22:01, Dean Landolt <d...@deanlandolt.com>wrote:
>>>> On Tue, Nov 23, 2010 at 3:34 PM, Irakli Gozalishvili <rfo...@gmail.com>wrote:
>>>>> Let me add few more arguments to my proposal:
>>>>> While I do like Kris Kowal's Q implementation and use it for all my >>>>> promise needs today, I think that promise spec can and should be more >>>>> minimal. I made an attempt to do so, obviously it may not look amazing but I >>>>> believe it can be shaped to an acceptable state. That being said I tried to >>>>> address few important points:
>>>>> 1. It satisfies opaque clause (I won't go into details on why is it >>>>> important, Kris did it already) >>>>> 2. Both Q and then chain-able promises can be built on top which will >>>>> make them interoperable. >>>>> 3. To my knowledge streaming is not well expressed by Q, IMO then-ables >>>>> are better with that, there for my proposal suggests a way to express steams >>>>> in opaque promise.
>>>> While I'm not 100% sure exactly what kind of streams you're referring to >>>> here I think this exposes a fundamental miscommunication. The functionality >>>> exposed by the signatures of each are equivalent in every way but one: >>>> `when` can handle non-promise (typed) values as well as promises. Thus, it >>>> is a superset of `then`. AFAIC the chainability of the `then` method is >>>> nothing more than a neat side-effect of the need to have a method key to >>>> specify on -- you can't rely on it with untrusted inputs and I can't see how >>>> it actually adds anything to make it more amenable to streams.
>>> In Q if I'm not miss-lead promise transitions from one state to another >>> and nothing like progress notifications exist. KrisZ had forEach-able >>> promises and then also accepts 3rd onProgress listener that may be called >>> for each delivered chunk.
>>>>> 4. I've started work on ES Harmony Proxy based promises, then-able >>>>> promises is no go there for obvious reasons, Q-is better, but 1. It comes >>>>> with lot's of stuff that is useless with Proxy based promises. 2. 'emit' >>>>> method on promise objects get's in the way. This is also addressed by >>>>> suggested proposal.
>>>>> I really don't want to come up with yet another promise implementation >>>>> that will be incompatible and will lead to even bigger fragmentation. All >>>>> needed is just a minimal spec that can address all the points mentioned. I >>>>> don't care whether it will be promise a/b/c or d as long all of this is >>>>> addressed.
>>>> I'm with you there. But AFAICT it's both better and worse than you >>>> think. A and B are almost identical -- interoperable in every way -- but the >>>> opaqueness constraint is a fundamental incompatibility. Promises/A solves >>>> interop nicely but at the cost of opacity. Promises/B is arguably more >>>> correct but requires you to use The One True Promise Library. Oh, and you >>>> have to make sure your code gets the same One True Promise Library as the >>>> libraries you're exchanging promises with. To date this is an unsolved >>>> problem.
>>> Well there is fundamental difference in way promises are chained, mainly >>> because of opacity. Unless Promise/A will respect that clause no >>> interoperability will be possible.
>> Yes, I know -- I was trying to point out that the APIs themselves are >> completely compatible but was making the point about opacity. That said, a >> Promise/A implementation could extend the One True Promise constructor to be >> interoperable with a Promise/B implementation. But this does absolutely >> nothing for my uneasiness about this assumption that require("promise") will >> always give you the right library. There's nothing in SecurableModules that >> can give you this guarantee. This isn't just an academic concern: the >> possibility of this or any promise implementation ending up in node >> approaches 0. So you've got to path shift. Unless we come up with something >> better dependency hell for opaque promises is virtually assured.
> Ok I see! I think that most of the nodejs community is on npm that sort of > guarantees that require('promise') will return the same thing or throw > regardless of combination of packages installed.
Quite the opposite AFAICT. The npm shims could lead to multiple versions of a promise lib being installed and used at any given time.
> Also here can be something like > require('commonjs/promise') that will provide base promise API that will be > used behind the scenes by both require('q') and require('promise') to > construct promises.
I think some kind of agreement on this require path would be absolutely *required. *It still doesn't completely solve the problem but it'd at least be a start.
