Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

which promise specification is used as blue print, e.g. all() vs. when() #12

Open
mgaerber opened this issue Feb 14, 2016 · 12 comments
Open

Comments

@mgaerber
Copy link
Contributor

jQuery and Q (Promises/A+) have a few differences in functionality and terminology, as covered here: Coming from jQuery: Q Promises

Q has a static when() function that has different semantics: Q.when

@james-jw
Copy link
Owner

First, I would say I have failed to truly align with either; however, with that said. I am certainly closer to the JQuery.

For example Q.js uses catch, while I choose jquery's fail, primarily due to using it more often. What would be your opinion? Thinking about it now, I think catch actually makes more sense.

Additionally a few changes were made to align more with the nature of XQuery.

In regards to when, it is analogous to JQuery's when method or Q's all method, except unlike in Q.js, it accepts a mix of promises, raw values (static) or single arity functions, instead of just a sequence of promises. Its purpose is not around static vs non static, but around using multi arity functions in a pipeline.

For example:

let $phrase := 'Hello'
let $name := p:defer(api:getName(?), '23')
return
  p:when(($phrase, $name))
    => p:then(function ($phrase , $name) { $phrase || $name });

Raw values are actually not supported due to oversight on my part in the current build out there. Ill fix that here quick, still recovering. ;0

There is a lot of stuff which doesn't transfer, or atleast need not, from javascript. For example, I don't have an any clause.

Thoughts?

@james-jw
Copy link
Owner

I think I completely missed one piece of this pattern in this implementation and what you were eluding to. Basically I didn't account for a very important facet to this pattern, the returning of a promise from a callback. The idea labelled by Q as static or non static.

let $greet:= function ($name) {
  let $greeting:= if($name = 'world') then $greet-world else $greet-non-world
  return p:defer($greeting, $name)
}
let $promise := p:defer($greet, 'world')
return
  $promise()

@james-jw
Copy link
Owner

So with all this said, I think this implementation proofs the pattern works, but I implemented the pattern slightly wrong. I agree we should decide on a template, and follow it all the way.

Luckily, whatever we choose will be a trivial change to actually implement.

What is your preference?

@james-jw
Copy link
Owner

Wholly crap... I can write this entirely in XQuery except fork and fork-join...

more to come...

@mgaerber
Copy link
Contributor Author

I tend to APIs with lighter footprint (jQuery in this case). On the other hand, the only official spec is A+ (also ECMA6) and I just read on the jQuery blog that they have a patch for jQuery 3.0 to align it with the spec.

Soo, in the end I guess A+ would be a good choice.

@mgaerber
Copy link
Contributor Author

Now having said that - A+ is only defining then semantics. Q just added everything else on its own. So apart from then there is no single source of truth...

@mgaerber
Copy link
Contributor Author

So, ECMA defines more methods, as always Mozilla MDN on Promise is a good read.

Promise.all() Promise.prototype.catch() Promise.prototype.then() Promise.race() Promise.reject() Promise.resolve()

Offical ECMA 2016 Spec: https://tc39.github.io/ecma262/#sec-promise-objects

@james-jw
Copy link
Owner

Thanks for the links! Now that the original library is converted to basically pure XQuery it will be easier to modify towards a goal of A+ coherence, at least as close as possible. I need to start with adding support for the reject callback. I think otherwise the conformance is rather close.

Not sure if the concepts of fufilled, pending, etc will apply with xquery...

@james-jw
Copy link
Owner

The then method should now behave like stated in the Offical ECMA 2016 Spec:
https://tc39.github.io/ecma262/#sec-promise-objects

With this, an additional overload accepts a reject callback. Additionally a fulfillment callback is not required. Multiple promises are also now supported.

Need to overhaul docs.

@james-jw
Copy link
Owner

when should be working as outlined for Q's all method:

Use the Q function to turn the non-promise values into promises, or pass an array to Q.all to get back a promise for an array of the results.

Are you seeing it operation differently. If you can give me an example query which operates out of sync It might be helpful.

@mgaerber
Copy link
Contributor Author

I'll soon add it to a project I am working on (for async image processing etc.) and tell you about my progress (or even add you to the repo)

@james-jw
Copy link
Owner

Sounds interesting! Keep me posted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants