Why implicit conversion is not applied to second argument? - scala

When I try to compile the following code
case class A(x: Int = 0)
object Conversions {
case class Converter[T](c: T) {
def +[U](that: Converter[U]): String = "worked"
}
implicit def convert(c: A): Converter[A] = Converter[A](c)
implicit def convert(c: Int): Converter[Int] = Converter[Int](c)
}
object Main extends App {
import Conversions._
val a: String = A() + A()
val b: String = 1 + A() // FAIL
val c: String = A() + 1
val d: Int = 1 + 1
}
I get the following error message
error: type mismatch; found: A; required: String
What is the difference between Int and A, so that expression b fails, while a and c pass? What do I do to make it compile?

First, the difference is that Int already has another + method, which expects another Int and returns an Int;
If you add a similar method to A you'd get similar failures:
case class A(x: Int = 0) {
// this would be similar to Int's plus operation:
def +(other: A): A = A(x + other.x)
}
// now these would behave "symmetrically":
val a: A = A() + A()
val b: String = 1 + A() // FAIL
val c: String = A() + 1 // FAIL
val d: Int = 1 + 1
As for why that fact causes this specific failure - that's trickier, I assume it has to do with the order in which the compiler tries to "choose" the right implicit conversion based on the left and right argument.

If you replace the arithmetic + operator with, say plus:
def plus[U](that: Converter[U]): String = "worked"
your implicit conversions should work the way you expect:
val a = A() plus A() // worked
val b = 1 plus A() // worked
val c = A() plus 1 // worked
val d = 1 plus 1 // worked
Rather than a direct implicit conversion between Int and A, your implicit conversions are between Int and class Converter (and, between A and Converter). The compiler apparently is having a hard time sorting through the conversion rules between Int and A when it sees a + method well defined for Int – unless you provide a direct implicit conversion between Int and A like in the following example:
object A {
implicit def intToA(n: Int): A = A(n)
}
case class A(x: Int = 0) {
def +(that: A): A = A(this.x + that.x)
}
val a = A(1) + A(2) // A(3)
val b = 1 + A(1) // A(2)
val c = A() + 1 // A(1)
val d = 1 + 1 // 2

I have no clear understanding on why this attempt was successful, but I hope that it will be useful to other users. Here I'm matching on both arguments at the same time to minimize Scala's attempts to bruteforce correct tree of implicit conversions.
object Defs {
case class A(x: Int = 1)
case class B(x: Int = 2)
trait IsExpr[T] {
def conv(v: T): Int
}
implicit object aIsExpr extends IsExpr[A] {
override def conv(v: A): Int = v.x
}
implicit object bIsExpr extends IsExpr[B] {
override def conv(v: B): Int = v.x
}
implicit def canSum1[A, B](a: A, b: B)(implicit ca: IsExpr[A], cb: IsExpr[B]): Int = ca.conv(a) + cb.conv(b)
implicit def canSum2[A](a: A, b: Int)(implicit ca: IsExpr[A]): Int = ca.conv(a) + b
implicit def canSum3[A](a: Int, b: A)(implicit ca: IsExpr[A]): Int = a + ca.conv(b)
implicit def convert[A](a: A) = new {
def +[B](b: B)(implicit f: (A, B) => Int): Int = f(a, b)
}
}
object Main extends App {
import Defs._
val a: Int = A() + A()
val b: Int = 1 + A()
val c: Int = A() + 1
val d: Int = 1 + 1
}

Related

Why doesn't Scala keep track of anonymous types?

In particular, this minimal example:
trait A[T1, T2] {
def convert(t1: T1): T2
def reverse(t2: T2): T1
}
class B extends A[Int, Double] {
def convert(i: Int): Double = i.toDouble
def reverse(i: Double): Int = i.toInt
}
class C extends A[Int, Float] {
def convert(i: Int): Float = i.toFloat
def reverse(i: Float): Int = i.toInt
}
val bOrC: A[Int, _] = if (System.nanoTime % 2 == 0) {
new B
} else {
new C
}
bOrC.convert(7)
bOrC.reverse(bOrC.convert(7))
Will fail on the last line:
scala> bOrC.reverse(bOrC.convert(7))
<console>:12: error: type mismatch;
found : (some other)_$1(in value bOrC)
required: _$1(in value bOrC)
bOrC.reverse(bOrC.convert(7))
It seems that the type of _$1 is the same in both the return type and the argument - it's bOrC's T2 type, whatever it may be. Local type inference shouldn't be a problem here. Why can't I do this?
Is there a workaround that isn't as ugly as the following?
trait A[T1, T2] {
def convert(t1: T1): T2
def reverse(t2: X): T1
type X = T2
}
// ... rest as before
bOrC.reverse(bOrC.convert(7).asInstanceOf[bOrC.X])
Edit: looks like if you tell Scala it's the same type, everything is handled. This gets rid of the silly type X:
def thereAndBack[T2](a: A[Int, T2], b: Int) = a.reverse(a.convert(b))
thereAndBack(bOrC)
Perhaps you can treat A as a typeclass and only have one of B / C available implicitly?
def convert[T1, T2](x: T1)(implicit a: A[T1, T2]): T2 = {
a.convert(x)
}
def reverse[T1, T2](x: T2)(implicit a: A[T1, T2]): T1 = {
a.reverse(x)
}
implicit val b = new B
// or implicit val c = new C
convert(7)
reverse(convert(7))

Merging multiple case (in match/case) in Scala

I have the code that instance.get returns value, and based on the type I process accordingly.
instance.get match {
case v:Range => {
val sizeInBytes = util.conversion.Util.getBytesForBits(v.size)
val value = v.decode(contentByteArray.slice(index, index + sizeInBytes))
index += sizeInBytes
res(key) = value
}
case v:Encoding => {
val sizeInBytes = util.conversion.Util.getBytesForBits(v.size)
val value = v.decode(contentByteArray.slice(index, index + sizeInBytes))
index += sizeInBytes
res(key) = value
}
...
}
In the code, I have duplication for the Range and Encoding type. How can I merge the two cases?
I tried the | operator, but it doesn't work.
case v:Range | v:Encoding
This can't work, because Range.size and Encoding.size are two completely different methods despite the fact that they are named the same. And same is true for Range.decode and Edncoding.decode.
So, when you write v.size, the type of v has to be known, it has to be either v:Encoding or v:Range, not v:Encoding|v:Range.
How to fix this? Make a common trait like this:
trait SomethingWithDecodeAndSize {
def size: Int
def decode(bytes: Array[Byte]): Whatever
}
And then, change the definitions of Range and Encoding:
class Range extends SomethingWithDecodeAndSize { ... }
class Encoding extends SomethingWithDecodeAndSize { ... }
Now you can just do case v: SomethingWithDecodeAndSize => ... in your match clause.
Also ... Don't do instance.get, that's bad taste. Do instead
instance match {
Some(v: SomethingWithDecodeAndSize) => ...
}
Update
If you cannot modify the definitions of the original classes, you can use an extractor:
object SomethingWithDecodeAndSize {
def unapply(a: Any): Option[SomethingWithDecodeAndSize] = a match {
case r: Range => Some(new SomethingWithDecodeAndSize {
def size = r.size
def decode(bytes: Array[Byte]) = r.decode(bytes)
})
case r: Encoding => Some(new SomethingWithDecodeAndSize {
def size = r.size
def decode(bytes: Array[Byte]) = r.decode(bytes)
})
case _ => None
}
}
Now, you can do case Some(SomethingWithDecodeAndSize(v)) => ... in your match.
An alternate solution to #Dima's in case you can't change definition of Range and Encoding (and there is no supertype with required methods):
trait RangeOrEncoding {
def size: Int
def decode(bytes: Array[Byte]): Whatever
}
implicit def liftRange(r: Range): RangeOrEncoding = new RangeOrEncoding {
def size = r.size
def decode(bytes: Array[Byte]) = r.decode(bytes)
}
// similar conversion for Encoding
// can also be a local def
private def handleRangeOrEncoding(v: RangeOrEncoding) = {
val sizeInBytes = util.conversion.Util.getBytesForBits(v.size)
val value = v.decode(contentByteArray.slice(index, index + sizeInBytes))
index += sizeInBytes
res(key) = value
}
instance match {
case Some(v: Range) => handleRangeOrEncoding(v)
case Some(v: Encoding) => handleRangeOrEncoding(v)
...
}
I remember the cheerleaders in high school asking us, "How loose is your goose?"
scala> class C { def f(i: Int) = 2 * i }
defined class C
scala> class D { def f(i: Int) = 3 * i }
defined class D
scala> def test(x: Any) = x match { case y: { def f(i: Int): Int } => y.f(42) }
<console>:11: warning: a pattern match on a refinement type is unchecked
def test(x: Any) = x match { case y: { def f(i: Int): Int } => y.f(42) }
^
warning: there was one feature warning; re-run with -feature for details
test: (x: Any)Int
scala> test(new C)
res0: Int = 84
scala> test(new D)
res1: Int = 126
scala> test(42)
java.lang.NoSuchMethodException: java.lang.Integer.f(int)
at java.lang.Class.getMethod(Class.java:1786)
at .reflMethod$Method1(<console>:11)
at .test(<console>:11)
... 32 elided
I believe the answer was: "Loose, baby, loose."
Edit:
scala> import reflect.runtime._,universe._,language.reflectiveCalls
import reflect.runtime._
import universe._
import language.reflectiveCalls
scala> class C { def f(i: Int) = 2 * i }
defined class C
scala> class D { def f(i: Int) = 3 * i }
defined class D
scala> def f[A](a: A)(implicit tt: TypeTag[A]) = a match {
| case b: { def f(i: Int): Int }
| if tt.tpe <:< typeOf[{ def f(i: Int): Int }] =>
| b.f(42)
| }
<console>:19: warning: a pattern match on a refinement type is unchecked
case b: { def f(i: Int): Int }
^
f: [A](a: A)(implicit tt: reflect.runtime.universe.TypeTag[A])Int
scala> f(new C)
res0: Int = 84
scala> f(new D)
res1: Int = 126
scala> f(3) // now an ordinary MatchError
scala.MatchError: 3 (of class java.lang.Integer)
at .f(<console>:18)
... 32 elided
So you can express it as an ordinary type bounds:
scala> def f[A <: { def f(i: Int): Int }](a: A) = a.f(42)
f: [A <: AnyRef{def f(i: Int): Int}](a: A)Int
scala> f(new C)
res3: Int = 84
scala> f(17)
<console>:20: error: inferred type arguments [Int] do not conform to method f's type parameter bounds [A <: AnyRef{def f(i: Int): Int}]
f(17)
^
<console>:20: error: type mismatch;
found : Int(17)
required: A
f(17)
^
You still need to accept the cost of the reflective call, of course.

Inheritance : override in class constructor

I am reading the example in this link http://www.tutorialspoint.com/scala/scala_classes_objects.htm
Example :
class Point(val xc: Int, val yc: Int) {
var x: Int = xc
var y: Int = yc
def move(dx: Int, dy: Int) {
x = x + dx
y = y + dy
println ("Point x location : " + x);
println ("Point y location : " + y);
}
}
class Location(override val xc: Int, override val yc: Int,
val zc :Int) extends Point(xc, yc){
var z: Int = zc
def move(dx: Int, dy: Int, dz: Int) {
x = x + dx
y = y + dy
z = z + dz
println ("Point x location : " + x);
println ("Point y location : " + y);
println ("Point z location : " + z);
}
}
object Test {
def main(args: Array[String]) {
val loc = new Location(10, 20, 15);
// Move to a new location
loc.move(10, 10, 5);
}
}
I didn't understand the utility of override keyword in class location constructor !
Why it is mentioned since we have an extends here ?
Thanks !
Given
scala> class A(val a: Int)
defined class A
If you try to define B like this:
scala> class B(val a: Int) extends A(a)
<console>:11: error: overriding value a in class A of type Int;
value a needs `override' modifier
class B(val a: Int) extends A(a)
compiler complains because it looks like you are trying to define a member a in class B and it already exists there through inheritance (from A). You need to add override to be explicit about your intentions in this case:
scala> class B(override val a: Int) extends A(a)
defined class B
More specifically you don't have to provide an override if you are overriding abstract members:
scala> trait A { def a: Int }
defined trait A
scala> class B(override val a: Int) extends A
defined class B
scala> class B(val a: Int) extends A
defined class B
However, to avoid unintended overrides when mixing in traits Scala protects you by requiring explicit override.
Consider this example:
No problem here:
scala> trait A { def a: Int = 1 }
defined trait A
scala> class B
defined class B
scala> new B with A
res0: B with A = $anon$1#3e29739a
You are saved from ambiguity:
scala> trait A { def a: Int = 1 }
defined trait A
scala> class B { def a: Int = 2 }
defined class B
scala> new B with A
<console>:13: error: <$anon: B with A> inherits conflicting members:
method a in class B of type => Int and
method a in trait A of type => Int
(Note: this can be resolved by declaring an override in <$anon: B with A>.)
new B with A
^
Resolve the conflict manually:
scala> trait A { def a: Int = 1 }
defined trait A
scala> class B { def a: Int = 2 }
defined class B
scala> new B with A { override val a = super[B].a }
res6: B with A{val a: Int} = $anon$1#76f6896b

Scala: require that a function argument is a member of some class?

I want to do something like
class A {
def f1: Unit = ...
def f2: Unit = ...
}
def foo(f: => Unit) {
(new A).f // ???
}
where f is supposed to be a member function of class A. I believe the standard solution is
def foo(f: A => Unit) {
f(new A)
}
and use it in this way
foo(_.f1)
foo(_.f2)
But now I can pass in an arbitrary function that has this signature, which may be not desired. Is there anyway to ensure that, the function I pass in is a member of certain class?
Well, if you don't mind a few contortions, you can use the fact that a function IS a class after all...
// abstract class MyIntToString extends (Int => String) // declare here if you want
// to use from different classes
// EDIT: f1 and f2 are now val instead of def as per comment below
// by #Régis Jean-Gilles
class A {
abstract class MyIntToString private[A]() extends (Int => String)
// if MyIntToString is declared here
// with a constructor private to the enclosing class
// you can ensure it's used only within A (credit goes to #AlexeyRomanov
// for his comment below)
val f1 = new MyIntToString {
def apply(i: Int) = i.toString + " f1"
}
val f2= new MyIntToString {
def apply(i: Int) = i.toString + " f2"
}
}
def foo(f: A#MyIntToString) = f(42) // f: MyIntToString if MyIntToString not nested in A
val a = A
now you can do:
scala> foo((new A).f1)
res1: String = 42 f1
scala> foo((new A).f2)
res2: String = 42 f2
but foo will not accept Int => String signatures
scala> val itos = (i:Int) => i.toString
itos: Int => String = <function1>
scala> foo(itos)
<console>:11: error: type mismatch;
found : Int => String
required: MyIntToString
foo(itos)
^

"Is almost a" relationships in Scala

I'm trying to design a class hierarchy with a bunch of similar classes that don't quite share a "is a" relationships. Let's call these Model classes. These classes are meant to be paired with a collection similar algorithms which make use the Model classes but do not identically have the same requirements. Let's call these Strategy classes. The trick is that the Strategy classes require many of the same things from the Model classes, but not all Model classes may be able to implement those required methods. I'd like to not have empty "stub" methods that will just throw UnsupportedOperationExceptions and instead have a type-safe mixin-based way of dealing with this -- is there a design pattern that I can apply?
For example,
object Main extends App {
trait A {
def f(one: Int): Int
def g(two: Int): Int
def h(three: Int): Int
}
class A1 extends A {
override def f(one: Int): Int = {one + 1}
override def g(two: Int): Int = {two + 2}
override def h(three: Int): Int = {assert(false); 0}
}
class A2 extends A {
override def f(one: Int): Int = {assert(false); 0}
override def g(two: Int): Int = {two - 2}
override def h(three: Int): Int = {three - 3}
}
trait B {
def combine(i: Int): Int
}
trait B1 extends B {
this: A =>
override def combine(i: Int) = {f(i) + g(i)}
}
trait B2 extends B {
this: A =>
override def combine(i: Int) = {g(i) + h(i)}
}
override def main(args: Array[String]): Unit = {
val a11 = new A1 with B1
val a22 = new A2 with B2
println(a11.combine(3))
println(a22.combine(3))
val a12 = new A1 with B2
println(a12.combine(3))
}
}
Here A is a Model class and B is the Strategy class. Notice that A1 may not be able to implement h() and that A2 may not be able to implement f(), and depending on the strategy class this may or may not be a problem. I'd like to be able to find out which implementation of A can work with which implementation of B at compile time.
I've used self-types to express a more "has a" than "is a" relationship that would normally go with extension.
Here my solution:
trait F { def f(one: Int): Int }
trait G { def g(two: Int): Int }
trait H { def h(three: Int): Int }
trait A
trait A1 extends A with F with G {
def f(one: Int): Int = { one + 1 }
def g(two: Int): Int = { two + 2 }
}
trait A2 extends A with G with H {
def g(two: Int): Int = { two - 2 }
def h(three: Int): Int = { three - 3 }
}
trait B {
def combine(i: Int): Int
}
trait B1 extends B {
this: A with F with G =>
def combine(i: Int) = { f(i) + g(i) }
}
trait B2 extends B {
this: A with G with H =>
def combine(i: Int) = { g(i) + h(i) }
}
val a11 = new A1 with B1
val a22 = new A2 with B2
println(a11.combine(3))
println(a22.combine(3))
val a12 = new A1 with B2 // won't compile as you wanted
You could also use structural types, the classes don't even need to be related in their hierarchy:
class A1 {
def f(i: Int) = {i + 1}
def g(i: Int) = {i + 2}
}
class A2 {
def g(i: Int) = {i * 2}
def h(i: Int) = {i * i}
}
type FnG = { def f(i: Int): Int; def g(i: Int): Int}
class B {
def combine1(a: FnG, i: Int) = a.f(i) + a.g(i)
def combine2(a: { def g(i: Int): Int; def h(i: Int): Int}, i: Int) =
a.g(i) + a.h(i)
}
val a1 = new A1
val a2 = new A2
val b = new B
println(b combine1(a1, 3))
println(b combine2(a2, 3))
trait C {
def combine(i: Int): Int
}
trait C1 extends C {
this: FnG =>
def combine(i: Int) = f(i) + g(i)
}
trait C2 extends C {
this: { def g(i: Int): Int; def h(i: Int): Int} =>
def combine(i: Int) = g(i) + h(i)
}
val newA1 = new A1 with C1
val newA2 = new A2 with C2
println(newA1 combine(3))
println(newA2 combine(3))
This way, you only need to specify (for traits) that the base types supports specific methods, and for classses, that the passed in class supports specific methods. You don't need to assume any hierarchy.