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

[christian-bick]

I have started to write future/promise wrappers for the Scala vert.x API for the most common use-cases along with writing my actual project code. The amount of needed project code decreased while its readability increased dramatically. I highly engourage to head for such an API.

By the way: My approach was to define an equivalent trait (self: VertxAccess => ...) for every vert.x API class with equivalent future implementations wherever applicable and practible. I like to be able to fall back to vert.x callback-driven API where this feels to be the better way to go (e.g. handler registration).

[galderz]

@christian-bick We're already working on the future/promise API, see the lengthy post I sent to the Vert.x users group a while back. However, Future/promises solve only one part of the API: single shot events. Multi-shot events (e.g. handling http requests) are not well suited here, which are more like streams of events (or rx) are a bit more tricky. The important thing to understand is that in the next major Vert.x version, we'll be moving towards generation of Scala APIs, based on our recommendations on how to map each concept to Scala. You might want to look at my prototype on the things we want to improve for next major Vert.x Scala API version.

[sscarduzio]

About multi-shot events: as Galder said, there's a number of solutions to
this problem in Scala in a clean way WITHOUT callbacks.

RX Observable is one of them, in Play they have Iteratees, but the cleanest
and most simple one I found is scalaz-stream (
https://github.com/scalaz/scalaz-stream)

You can see this widely explained in the last chapter of the book
"Functional Programming In Scala", but the github project has some docs too.
A thing I really like in scalaz-stream is the ability to use combinators
(map, filter, take,..) on a stream as you would do on a collection.

This in my opinion would be the most Scala idiomatic and functional
approach.

On Thu, Aug 7, 2014 at 6:41 PM, Galder Zamarreño [email protected]
wrote:

@christian-bick https://github.com/christian-bick We're already working
on the future/promise API, see a the lengthy post
https://groups.google.com/forum/?fromgroups=#!topicsearchin/vertx/scala/vertx/9Zbmw2wa5mU
I sent to the Vert.x users group a while back. However, Future/promises
solve only one part of the API: single shot events. Multi-shot events (e.g.
handling http requests) are not well suited here, which are more like
streams of events (or rx) are a bit more tricky. The important thing to
understand is that in the next major Vert.x version, we'll be moving
towards generation of Scala APIs, based on our recommendations on how to
map each concept to Scala. You might want to look at my prototype
https://github.com/galderz/next-vertx-scala on the things we want to
improve for next major Vert.x Scala API version.

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

[galderz]

I ordered that book when it was on MEAP and hopefully tomorrow the final version of the ebook should be out. I'll be reading it in the next few weeks :).

However, the main issue of scalaz-stream is that it brings a dependency, so we might include that in some extra module, and leave the main scala module extension using basic callbacks (or maybe partial functions?), or something that's available within the main scala library. This is TBD for sure.

[aliakhtar]

Did this ever end up being added? ATM looking at the scala docs, there doesn't seem to be any support.