I don't think we should artificially restrict uncontroversial improvements. (Consider that fact that VisualVM was first bundled with JDK 6 update 7- without doubt it was good to ship it then rather than delaying until JDK 7.)
Maybe we want something else for Scala, but we need to think of the ramifications and the recommendations for library authors (maybe they always stick to .0 to give flexibility to library users).
If the only problematic aspect of adding api in a point release is people compiling against it and losing compatibility with earlier point releases, we could also annotate new elements and require you to give a compiler option to use those from source.
Or, we could offer a MIMA-like tool that inspects your code and checks that it only calls methods defined in 2.10.0. This wouldn't rely on use remembering to mark new methods as experimental.
+1 ... People that decide to use Scala futures today have to roll their own set of helpers to deal with timeouts and such. Most just use Akka's or Twitter's.
Create an extension to SIP-14 and invite people to participate in it. I'll chime in for sure.
Cheers,
V
" It would be wonderful to gain a scala implementation of Cap’n Proto," <-- sounds like a specific integration to me? I don't see why that should be in the Scala Standard Library.
For me, it sounds like Rob wants to have something like this, not exact integration. But in any way, I do not see it as a part of futures & promises because Cap’n Proto is about RPC, is not it?
The capabilities this standard offers are quite powerful and not present in scala. What is the use of futures/promises with no RPC between processes? Aren’t you wanting to build a promise library to help with concurrent processing? Is it useful to have concurrent processing with no distribution
The only things really needed are the ability to send to a promise and to use them as typed arguments in calls.
The capabilities this standard offers are quite powerful and not present in scala. What is the use of futures/promises with no RPC between processes? Aren’t you wanting to build a promise library to help with concurrent processing? Is it useful to have concurrent processing with no distributionIn general, they are used for asynchronous computations, it does not meter whey they happen – locally or remotely. For example, you can use Akka without communication with the world. Another one is Finagle, there is no any sense to use it in scope of the single process. All these examples have one thing in common: they all are built in pair with the futures. They are not trying to extends them, they are trying to use them to build much more complex frameworks. It requires having futures and promises quite simple, easy to use, and without strict contract that makes others to do things in only one right way.Current simplicity of the futures is fine, but as we can see Twitter, Akka, and others have a lot of tasty stuff which may also be used as a part of Scala's Futures and Promises.
The only things really needed are the ability to send to a promise and to use them as typed arguments in calls.Could you show an example of this?
Ref answer = alice.redirectMessage("redirectForTheAnswer", bob).redirectMessage("hashCode");This sends to alice with bob as an argument. The method redirectForTheAnswer forwards a send to bob for the method getTheAnswer. The hashCode send is a pipeline send and is forwarded to alice to be sent when the result resolves over there. Since the pipeline send is to the result of redirectForTheAnswer, it does not get forwarded to bob. Note that due to the typing issue, I have to specify a Ref as the parameter to the method redirectForTheAnswer.Thank you,charlie
On Sunday, January 5, 2014 10:22:46 PM UTC+2, Rob Withers wrote:On Jan 5, 2014, at 9:51 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:" It would be wonderful to gain a scala implementation of Cap’n Proto," <-- sounds like a specific integration to me? I don't see why that should be in the Scala Standard Library.That is a reasonable argument to make about a vender integration, but this is not necessarily such. I would point out that there are 2 layers to Cap’n Proto.There is the encoding. This is nice to have, for sure and that would be an interesting exercise for a vendor integration. It is just one more message structure specification, but quite interesting. It is firmly in the session layer.There is also the RPC protocol specification. As long as there is support for specifying the encoding in the startup protocol, when rendezvous occurs, then the implementation of the underlying encoding can be varied. The same is true of many of the details of coordination, in the session layer, like encryption and protocol version.However, there is also the upper layer of the RPC protocol, which is the remote object refs, object tables and promises. It has the execution semantics of an event loop, but with the ability to wait and pause a continuation. Placing that presentation layer on top of a negotiated session is not a vendor specific set of thing. It is supporting a common protocol standard. It was derived from Elib.The whole point of distributed event loops and promise pipelining is to spread the stack of execution between event loop queues, between processes. This is interesting. The only things really needed are the ability to send to a promise and to use them as typed arguments in calls. Also need the ability to mutate, but that is achievable in scala, I think, using a for-comprehension.On Jan 5, 2014, at 10:09 AM, Anton Kolmakov <an...@kolmakov.me> wrote:For me, it sounds like Rob wants to have something like this, not exact integration. But in any way, I do not see it as a part of futures & promises because Cap’n Proto is about RPC, is not it?The capabilities this standard offers are quite powerful and not present in scala. What is the use of futures/promises with no RPC between processes? Aren’t you wanting to build a promise library to help with concurrent processing? Is it useful to have concurrent processing with no distribution?- charlie (now preferred, as I buried the old me, dead and gone)
--
You received this message because you are subscribed to the Google Groups "scala-sips" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-sips+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
... So I did not know Akka and other frameworks all use Scala futures and promises. So the Scala Standard Library support for futures and promises are a generalized asynchronous framework used by many implementations.
I see. A general recommendation, where Akka is one implementation of an actor model in Scala. However, Akka does not support promise pipelining,
so it does not have the optimization characteristics of dealing with latency in the way Elib does.
It does not stretch the execution environment in the way Elib does. Elib is itself an actor model, plus continuations and promise pipelining. Is there another actor model implementation, in scala, which is closer to Elib's mark?
On Mon, Jan 6, 2014 at 5:55 PM, charlie robert <charlie...@icloud.com> wrote:
I see. A general recommendation, where Akka is one implementation of an actor model in Scala. However, Akka does not support promise pipelining,Of course it does: you get "promise pipelining" if you use Actors instead of Futures.
so it does not have the optimization characteristics of dealing with latency in the way Elib does.Example?
It does not stretch the execution environment in the way Elib does. Elib is itself an actor model, plus continuations and promise pipelining. Is there another actor model implementation, in scala, which is closer to Elib's mark?
Well that was my point, you have a great testbed to implement whatever you want on top of Akka's actors, you get remoting, clustering, distributed fault detection etc for "free".
I just read the Scala Actors tutorial and I do not see support for pipelining. Can a message be sent to an unresolved future, in Akka? Of not, then there is no pipelining and no stretched stack. This misses the core feature.On Mon, Jan 6, 2014 at 5:55 PM, charlie robert <charlie...@icloud.com> wrote:
I see. A general recommendation, where Akka is one implementation of an actor model in Scala. However, Akka does not support promise pipelining,Of course it does: you get "promise pipelining" if you use Actors instead of Futures.
Please look at the Cap'n Proto link on RPC and look at the topmost diagram.so it does not have the optimization characteristics of dealing with latency in the way Elib does.Example?