implicit

In the Scala Collections framework, I think there are some behaviors that are counterintuitive when using map() . We can distinguish two kinds of transformations on (immutable) collections. Those whose implementation calls newBuilder to recreate the resulting collection, and those who go though an implicit CanBuildFrom to obtain the builder. The first category contains all transformations where the type of the contained elements does not change. They are, for example, filter , partition , drop , take , span , etc. These transformations are free to call newBuilder and to recreate the same

I am trying to create an implicit conversion from any type (say, Int) to a String... An implicit conversion to String means RichString methods (like reverse) are not available. implicit def intToString(i: Int) = String.valueOf(i) 100.toCharArray // => Array[Char] = Array(1, 0, 0) 100.reverse // => error: value reverse is not a member of Int 100.length // => 3 An implicit conversion to RichString means String methods (like toCharArray) are not available implicit def intToRichString(i: Int) = new RichString(String.valueOf(i)) 100.reverse // => "001" 100.toCharArray // => error: value toCharArray

I made codes using play framework in scala which look like the following: object Application extends Controller { def hoge = Action( implicit request => val username = MyCookie.getName.get Ok("hello " + username) } } object MyCookie { def getName( implicit request: RequestHeader ) = { request.cookies.get("name").map(_.value) } } I got a code review from my coworker. He said this code is not readable because of implicit parameter. I couldn't reply to his opinion. So could you tell me what is the best way to use implicit parameters? When should I use implicit parameters? You should use implicit

Update! See my dissection of a portion of the C# spec below; I think I must be missing something, because to me it looks like the behavior I'm describing in this question actually violates the spec. Update 2! OK, upon further reflection, and based on some comments, I think I now understand what's going on. The words "source type" in the spec refer to the type being converted from -- i.e., Type2 in my example below -- which simply means that the compiler is able to narrow the candidates down to the two operators defined (since Type2 is the source type for both). However, it cannot narrow the

I am designing an API using type classes in some cases however I have encountered a problem with implicit resolution. As shown below, if there is an implicit object for type A but an object of type B extends A is passed to the method, then an implicit object cannot be found. Is there a way to make this work or do callers have to put implicit objects into scope for each subclass? Here is an example: class A class B extends A class T[+X] object T { implicit object TA extends T[A] } def call[X:T](x:X) = println(x) // compiles call(new A) // doesn't compile call(new B) var a = new A // compiles

I've been reading some stuff on Scala type level programming. Mainly the Apocalisp blog, and also a youtube talk by Alexander Lehmann. I am a bit stuck on something which I guess is probably very basic, which is the use of implicitly to compare two types as shown below: implicitly[Int =:= Int] Mark on the Apocalisp blog says: This is useful for capturing an implicit value that is in scope and has type T. I get how to make this work, but I don't really know why it works and so don't want to move on. In the case above is there an implicit of type 'Int' in scope, that 'implicitly' plucks from the