Hi Giovanni, On Mon, Feb 16, 2015 at 11:31 PM, Giovanni Alberto Caporaletti < [email protected]> wrote:
> You're absolutely right about the future not representing an "already > running computation". But it's not a "blueprint". If a see a future, I take > for granted that something will happen sooner or later. If I see a source > and I don't materialize it, nothing will ever happen if it's cold. > That's absolutely correct—a Future is not a blueprint. To get a blueprint for it you'd need () => Future[X] > > Regarding those use cases, I'm not that extreme, but for a single item > observable/stream I think it would be really useful to have that > abstraction, mostly because a lot of my code is based on the assumption > that the observable will return exactly one item. > But it cannot be proven as an Exception (or rather a Throwable) could be thrown at any point in time in the execution of that Source. (StackOverFlowError, ThreadDeath, OutOfMemoryError etc) Making assumptions is OK, but one needs to consider the failure cases (because they do tend to occur in practice). > > Maybe it's just me but i find really helpful to have "talking" signatures. > E.g. if I saw in an api a data lookup method 'def retrieveUserByName(name: > String)', knowing that it returns a SingleItemStream[User] instead of a > Stream[User] would help a lot because it'd be immediately clear that name > is a unique attribute of the user. I really think that this expressive > power, when consistent all over the codebase, is of great help. > I completely agree, being able to have the type system prove things for us is really neat, but unfortunately it is not really feasible to track source sizes—what's good is that you can create, as Endre nicely points out, a value class wrapper for some of them. It should be noted that a Future[T] really has 3 outcomes: never completed, value or Exception > > Sorry if something I wrote is not correct, I started studying > reactive/asynchronous programming only recently and I'm grateful to whoever > helps me to understand it :) > No need to apologize! :) > > Cheers > G > > On Monday, 16 February 2015 21:29:10 UTC, √ wrote: >> >> Giovanni, >> >> On Mon, Feb 16, 2015 at 9:37 PM, Giovanni Alberto Caporaletti < >> [email protected]> wrote: >> >>> What I'm saying is that conceptually having a single item or a stream >>> are two different things and this should be reflected in the type system >>> (e.g. rx Task). >>> >> >> I disagree and let me tell you why :) Think about it—Stream subsumes >> Future: there is no type that reflects an empty stream, there is no type >> that discerns bounded from unbounded streams, hot or cold streams, no type >> for bounded streams of size N, no type for this is a stream that fails >> after N elements… >> If you were to provide types for all these very important >>shapes<< of >> streams you'd end up executing the streams inside the compiler when you try >> to typecheck the program. >> >> >>> What you're suggesting is implementation details, the assumption that a >>> source will only emit 1 item is nowhere to be seen in the type. >>> if I have a signature that returns (or takes) a Stream[T] I don't see >>> the constraint that that stream will never have more than 1 item. >>> >>> A Future is a very different animal from the Stream, especially because >>> it represents a computation that's already happening. >>> >> >> The statement regarding Future is provably false: >> >> Let me present Exhibit A: >> >> val p = Promise[Pigdog]() >> >> val f = p.future // is f an already running computation? >> >> One of the most prevalent misconceptions is that Futures are inherently >> about computation—they're not :) Future are about facts which may or may >> not be available at a specific point in time. I think the source of the >> confusion is twofold: Future.apply and Future.<transformations>, in fact, >> if Future only had the `onComplete` method one could create typeclasses >> that would provide -all- of the functionality already available for Future >> (of course given that Promise allows for populating it with a value). >> >> >>> I have no way (afaik) of expressing in a type signature that "this is a >>> blueprint for a source of a single (or zero) item". >>> >>> Look at the rx Observable.single method. It does that but it doesn't >>> express it in the type system (as Task does). A lot of use cases involve >>> Observables/Producers/Sources that can possibly have only one item, hence >>> this PR: https://github.com/ReactiveX/RxJava/pull/2641. >>> >>> >> But don't get me wrong, it doesn't mean that Future (or rx.Task) isn't >> useful, quite the contrary, but stream is provably more useful (since it >> supports more usecases). >> >> >>> >>> On Monday, 16 February 2015 18:41:07 UTC, Jim Hazen wrote: >>>> >>>> These days the current API supports a number of ways of constructing a >>>> Source. >>>> >>>> http://doc.akka.io/api/akka-stream-and-http-experimental/1. >>>> 0-M3/?_ga=1.72893075.1209102577.1407799351#akka.stream.scaladsl.Source$ >>>> >>>> Based upon these available methods, if I needed to supply 0 or 1 >>>> elements based upon some business logic, I would probably create a custom >>>> iterator implementation. Your business logic can then determine whether to >>>> emit an element or provide hasNext=false, which I believe will signal that >>>> the source is empty and trigger a teardown of the materialized flow. >>>> >>> -- >>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/ >>> current/additional/faq.html >>> >>>>>>>>>> Search the archives: https://groups.google.com/ >>> group/akka-user >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Akka User List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/akka-user. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Cheers, >> √ >> > -- > >>>>>>>>>> Read the docs: http://akka.io/docs/ > >>>>>>>>>> Check the FAQ: > http://doc.akka.io/docs/akka/current/additional/faq.html > >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user > --- > You received this message because you are subscribed to the Google Groups > "Akka User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Cheers, √ -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
