Re: The cake's problem, dotty design and the approach to modularity.

On 08/23/2015 09:05 PM, Shelby wrote:
> One issue I see with obligatory (versus optional) named parameters, is 
> I really wish Scala could do OCaml's (tuple and any other unapply) 
> destructing on the function parameters:
>
> |#let  distance(x1,y1)  (x2,y2)  =
>      sqrt((x1 -. x2)  **  2.+.(y1 -. y2)  **  2.)
>
> So in Scala:
>
> def distance((x1,y1), (x2,y2)) = ...
>
> And why can't Scala infer those types given sqrt inputs Float? One of the big complaints I hear is Scala can't infer types.
> |
|
||This is a complaint mostly by Haskell people or people doing lots of 
functional programming in general. Beside from a few cases I don't see 
this as very important. You don't want to have inferred argument types 
in public methods for any nontrivial project.|

> |
> Or at least why do I have to redeclare the types in a class that implements a trait where the types where already declared in the trait and there is no ambiguity?
> |
|You don't have to:
|
% s -Yinfer-argument-types
Welcome to Scala version 2.11.7 (OpenJDK 64-Bit Server VM, Java 1.7.0_85).
Type in expressions to have them evaluated.
Type :help for more information.

scala> trait T { def f(i: Int) = i }
defined trait T

scala> trait TT extends T { override def f(i) = i }
defined trait TT

-- 
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.