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

Hi Christoph,

The only reason this hasn't been done before is due to backwards
compatibility.

-- 
Cheers,
√
On 12 May 2015 17:34, "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.