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

Hi Viktor,

thanks, I guess that makes sense. The roadmap mentions an automatic 
migration tool (a la go fix for Go) is planned - maybe this change can be 
reconsidered when the work starts on that one?

On Tuesday, May 12, 2015 at 7:19:38 PM UTC+2, √iktor Klang wrote:
>
> 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] 
> <javascript:>> 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] <javascript:>.
>> 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.