Re: Failure should probably extend Try[Nothing], as shown in first lecture of Principles of Reactive Programming

I basically agree with you, but note that there are three concepts that are
useful:
  1. Try[A]  --  I might have an A, or I might have a failure
  2. Failure[A]  --  I tried to get an A, but I have a failure instead
  3. Failure  --  I don't know or care what I tried to get, but I know it
didn't work

The current implementation gives you 1. and 2., but not 3.; I agree,
especially given the covariance of Try and the methods on Try, that 1. and
3. are the more useful pair.  But occasionally it's nice to know what the
success type should have been (e.g. because you want to dispatch on it with
a type class), even though you're in the failure case.  (Refactoring is
possible, but it shifts work from the compiler to the programmer.)

So I agree that the other choice would have been better, but there is at
least _some_ advantage to the way it is.

  --Rex



On Tue, May 12, 2015 at 8:34 AM, Christoph Neijenhuis <
[email protected]> wrote:

> In the lecture Monads (slide 22), Try with Success and Failure was
> introduced. In particular, Failure was defined as:
>
> case class Failure(ex: Exception) extends *Try[Nothing]*
>
> However, in scala.util it is actually defined this way:
>
> final case class Failure[+T](exception: Throwable) extends *Try[T]*
>
> I tried to figure out why Failure would remain a generic class while e.g.
> None doesn't, but I couldn't come up with an explanation. In fact, I'd
> argue Failure, like None, should use the bottom type for two reasons:
>
> 1. When dealing with a Failure, one doesn't have to worry about a generic
> type that doesn't make any difference anyway. E.g. when pattern matching:
>
> case None => ... // Compiles
> case Failure => ... // Does not compile: "pattern type is incompatible
> with expected type"
> case Failure[_] => ... // Compiles, but is unintuitive when working with
> None previously
>
> Or when passing a failure along, one has to cast to the "correct" generic
> type (seen in the implementation of Failure itself, but this example is
> from the implementation of Future)
>
> case f: Failure[_] => p complete f.asInstanceOf[Failure[(T, U)]]
>
> When using the bottom type, this simply becomes:
>
> case f: Failure => p complete f
>
> 2. The method signatures and the generated scaladoc are more obvious. E.g.
> the get method of None is defined as:
>
> def get: Nothing
>
> whereas the get method of Failure is:
>
> def get: T
>
> I'd argue in the case of None, it's much easier to figure out one
> shouldn't use the get method based on the signature.
>
>
> I did go forward and changed the implementation of Failure:
> https://github.com/cneijenhuis/scala/commit/e03c6bda9d6c92b764f540278d718098e7778791#diff-a2cc47b875d07181ae9e71681fb3f07dL211
> But the resulting class is obviously not compatible with the previous
> version. I fixed the resulting errors in Future and JavapClass as well -
> these changes also show nicely why I think it's benificial to use Nothing.
>
> Anyway, my questions are:
> Is there a reason I missed why Failure should really be a generic class
> and not extend Try[Nothing]?
> If not - is there any chance I can submit a pull request with this? After
> all, it's a breaking change... but I do see those are scheduled for "Aida",
> and, while Try isn't a collection, this change would fit with the theme of
> "we want to make them even easier to use" :-)
>
> Best,
> Christoph
>
> --
> You received this message because you are subscribed to the Google Groups
> "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.