Provide a Scala Future/Promises based API

[Narigo]

In our projects, we use Futures and Promises to get rid of the nested callbacks. It would be very nice to have them in the API directly instead of having to write them myself.

If you want to stay tied to the Vert.x API, this could also be done as an extra, includable module. Not sure whether this makes much sense, though.

[galderz]

Narigo, it could be nice to have, I quite like the syntatic sugar you get with for-comprehensions together with Future/Promises. It'd imagine it'd an alternative/experimental API to start with? As you rightly say, we wanna stay close to Vert.x API...

Btw, do you have any link to your projects by any chance?

[nfmelendez]

Q javascript framework is a good example of what narigo proposes:

sphagetti:

step1(function (value1) {
step2(value1, function(value2) {
step3(value2, function(value3) {
step4(value3, function(value4) {
// Do something with value4
});
});
});
});

With a promise library, you can flatten the pyramid.

Q.fcall(step1)
.then(step2)
.then(step3)
.then(step4)
.then(function (value4) {
// Do something with value4
}, function (error) {
// Handle any error from step1 through step4
})
.done();

[Narigo]

Mostly everything we open sourced is here:

https://github.com/campudus

Check out the module registry, too. We've written it in Scala, added tests and have used Futures there a lot: https://github.com/vert-x/vertx-module-registry

[galderz]

I had a quick discussion today in the #vertx IRC channel with @purplefox and he said there's an Future/Promises-like API already available for Java in https://github.com/vert-x/mod-rxvertx. It uses RxJava to enable composition. I haven't looked at it yet, but one option would be wrap that around Scala Future/Promises and this nice, composable API.

I'm not sure there's a need for another API on top of Scala future/promises necessarily. On on side, future/promises already have flatmap() methods, which is what allows them to be composable in for-comprehension structures. But, even such API can be cumbersome, which is why the Scala Async project was created (https://github.com/scala/async).

I think we all agree on the merits of a future/promises based API, so should defo investigate that. And if we can align it with the equivalent one in Java, I think it'd be even better, although with Java8, I wonder what will happen to the rxvertx module...

Thx for the links @Narigo :)

[edgarchan]

I think it make sense at least try to fuse Scala futures with o.v.j.core.Future into mod-lang-scala for various reasons:

• Because it would be more natural from the Scala dev point of view.
• It would help to reduce the confusion between both implementations.
• Better interoperability with other mods written in java using futures.
• Both are part of the their corresponding standard libs (no third parties involved).
• o.v.j.core.Future exposes a small api
  https://github.com/vert-x/vert.x/blob/master/vertx-core/src/main/java/org/vertx/java/core/Future.java
• Scala Async operates on top of standard Future/Promise.
• And of course get rid of the nested callbacks.

[purplefox]

I would like to see an api that uses Scala Futures/Promises as I agree
that will be expected by most Scala devs.

However, I would like to take a layered approach

1. Create the core API wrappers in Scala that resemble the Java APIs,
   i.e. with callbacks, as you have done so far
2. Have another API that exposes Scala futures/promises that uses the
   API in 1.

Keep them nice and separate - don't put futures/promises in 1.

On 04/07/13 20:29, Edgar Chan wrote:

I think it make sense at least try to fuse Scala futures with o.v.j.core.Future into mod-lang-scala for various reasons:

• Because it would be more natural from the Scala dev point of view.
• It would help to reduce the confusion between both implementations.
• Better interoperability with other mods written in java using futures.
• Both are part of the their corresponding standard libs (no third parties involved).
• o.v.j.core.Future exposes a small api
  https://github.com/vert-x/vert.x/blob/master/vertx-core/src/main/java/org/vertx/java/core/Future.java
• Scala Async operates on top of standard Future/Promise.
• And of course get rid of the nested callbacks.

---

Reply to this email directly or view it on GitHub:
#16 (comment)

[nfmelendez]

This will add a great value to the project, and definitely should be in a separate package so a developers, only need to read the imports to know that futures are used somewhere in the code.

Nicolás Meléndez
Software Engineer

Twitter: @nfmelendez
Blog: http://blog.melendez.com.ar/
Github: https://github.com/nfmelendez
Linkedin: http://ar.linkedin.com/in/nicolasmelendez

Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Thursday, July 4, 2013 at 4:51 PM, Tim Fox wrote:

I would like to see an api that uses Scala Futures/Promises as I agree
that will be expected by most Scala devs.

However, I would like to take a layered approach

1. Create the core API wrappers in Scala that resemble the Java APIs,
   i.e. with callbacks, as you have done so far
2. Have another API that exposes Scala futures/promises that uses the
   API in 1.

Keep them nice and separate - don't put futures/promises in 1.

On 04/07/13 20:29, Edgar Chan wrote:

I think it make sense at least try to fuse Scala futures with o.v.j.core.Future into mod-lang-scala for various reasons:

• Because it would be more natural from the Scala dev point of view.
• It would help to reduce the confusion between both implementations.
• Better interoperability with other mods written in java using futures.
• Both are part of the their corresponding standard libs (no third parties involved).
• o.v.j.core.Future exposes a small api
  https://github.com/vert-x/vert.x/blob/master/vertx-core/src/main/java/org/vertx/java/core/Future.java
• Scala Async operates on top of standard Future/Promise.
• And of course get rid of the nested callbacks.

---

Reply to this email directly or view it on GitHub:
#16 (comment)

—
Reply to this email directly or view it on GitHub (#16 (comment)).

[galderz]

@purplefox @nfmelendez @edgarchan +1

[galderz]

In an IRC meeting earlier today, It was agreed that this API should be separated into a different Vert.x module.

[sscarduzio]

Hi, this issue is one year old and leaves the thread with a Promise to implement the Scala-style layer at some point in the Future. All puns intended ;)
I wonder if this ever happened. It feels really awkward to pass callbacks in Scala!

[galderz]

I've been working on a prototype for Vert.x 3.x but it's not ready yet, particularly because some callbacks are called several times, where Promise/Futures can't help.

[galderz]

@sscarduzio FYI, I've posted a basic prototype and some feedback in https://groups.google.com/forum/?fromgroups=#!topic/vertx/9Zbmw2wa5mU