Scala: add optionnal arguments to super method - scala

I'm trying to implement a trait as follow: (1)
trait FooLike {
def foo(x: Int): Int
}
class Foo extends FooLike {
def foo(x: Int, y: Int = 0): Int = x + y
}
But the compiler complains that the method foo(x: Int): Int is not implemented.
I can do: (2)
class Foo extends FooLike {
def foo(x: Int): Int = foo(x, 0)
def foo(x: Int, y: Int = 0): Int = x + y
}
But it feels like Java, and I don't like it ! Is there a way to avoid this boilerplate ?
I thought that def foo(x: Int, y: Int = 0) would define two methods in the background but apparently it's not the case. What's actually happening ?
--- EDIT : more weirdness ---
Also the following is perfectly legit: (3)
class Foo extends FooLike {
def foo(x: Int): Int = x - 1
def foo(x: Int, y: Int = 0): Int = x + y
}
while it doesn't seems reasonable (foo(4) = 3 while foo(4, 0) = 4).
I think that authorizing (1) and forbidding (3) would have been the most reasonable choice, but instead they made the opposite choice. So why did Scala make those choices ?

It is not possible to override a method of a different type signature in Scala by using default arguments. This is because of how default arguments are implemented. Default arguments are inserted when and where the method is applied, so there is only one version of the method being defined.
According to SID-1: Named and Default Arguments, when a method foo() with default arguments is compiled, only one method foo() is defined, which takes all the arguments. A call with default arguments like f.foo(xValue) is transformed at compile time into code equivalent to the following:
{
val x = xValue
val y = f.foo$default$2
f.foo(x, y)
}
The foo$default$2 method is a hidden method which takes no arguments and returns the default value of argument #2 to the method foo().
So while you can write the same exact functional application foo(xValue) for a method foo(x: Int) or a method foo(x: Int, y: Int = 0), the methods being called "behind the scenes" do not have the same type signature.

You are extending a trait which has a non implemented method, you must implement it in the extending classes or you can implement it in the trait, if you don't need the foo with a single variable you can do:
trait FooLike {
def foo(x: Int, y: Int): Int
}
class Foo extends FooLike {
def foo(x: Int, y: Int = 0): Int = x + y
}
But I suppose you do and so you have to give the compiler an implementation for it, to compare this case to Java, it's like when you extend an abstract class and you don't implement a method, the compiler will complain that either you implement the method or you declare the class abstract.
One other approach which came to mind and is fairly reasonable is to implement the method in the trait so:
trait FooLike {
def foo(x: Int): Int = x
}
class Foo extends FooLike {
def foo(x: Int, y: Int = 0): Int = x + y
}
Then if you want to add a new class with the trait mixed in but with a different method implementation just override the method:
class AnotherFoo extends FooLike {
override def foo(x: Int): Int = x + 1
}

Related

Overriding a trait method with a function value

Say I have a trait like this
trait X {
def foo(param: String): Int
}
and I want to override it with a function value, I have to do this:
class XImpl extends X {
private val fooF: String => Int = ???
override def foo(param: String): Int = fooF(param)
}
because the following does not work
class XImpl extends X {
override val foo: String => Int = ???
}
/*
error: class XImpl needs to be abstract. Missing implementation for:
def foo(param: String): Int // inherited from trait X
^
error: value foo overrides nothing.
Note: the super classes of class XImpl contain the following, non final members named foo:
def foo(param: String): Int
*/
Is it possible to directly implement/override the trait method with the function value in some way and avoid the forwarder?
The simple answer is that you cannot override a method with a function value because they are not the same type.
A method must be called on a particular instance of a class (even if the method itself does not use any fields in that class).
A function value stands alone and can be called without any additional information.
A method can be converted a function value using eta expansion x.foo _. This creates a function value which has the class value embedded within it.
val x: X = ???
val etaFoo: String => Int = x.foo _
In this case Scala will actually do the eta expansion for you so the _ is optional, but it is required in more complex uses and is good practice to keep it there so show that eta expansion is happening.
To convert a function value to a method you need to define a method as shown in the question.
Eta expansion works with methods with multiple parameters:
trait X2 {
def foo2(p1: String, p2: Int): String
}
val x2: X2 = ???
val etaFoo2: (String, Int) => String = x2.foo2 _

Scala Subclass change return type without override

Let's say I have a class called A:
class A(i: Int) {
//private def to initialize a calculated value
def maintainedValue : Int = calculatedValue
def double : A = new A(maintainedValue * 2)
def combine(other: A) : A = new A(maintainedValue + other.maintainedValue)
def addAmt(amt : Int) : A = new A(maintainedValue + amt)
// Many many more methods
}
I want to define a class B that extends class A such that it's methods, almost all of which have similar logic, return an object of class B:
class B(i: Int) extends A(i) {
//private def to initialize a differently calculated value
def maintainedValue : Int = diffCalculatedValue
//Change all other methods to return type B without override???
}
Is it possible to do this without overriding all the methods?
Is there a simple way to instantiate these new instances with a variable/dynamic class?
Perhaps there is a more elegant way to do this?
One solution, and the simplest one in my opinion, is to change class A to have a structure such that a single method handles object creation:
def create(i: Int): TYPE = new B(i)
And just use an implicit method in class B to handle casting when calling the unaltered methods:
private implicit def convert(a: A): B = new B(a.maintainedValue)
Short and sweet, though I'm curious how efficient and/or scale-able this solution is.
How about having base trait with common logic and two implementation?
object App extends App {
println(A(1).double)
println(B(1).double)
}
trait A {
type TYPE
def create(i: Int): TYPE
def maintainedValue: Int
def double: TYPE = create(maintainedValue * 2)
def addAmt(amt: Int): TYPE = create(maintainedValue + amt)
}
trait B extends A {
}
object A {
def apply(i: Int) = new AImpl(i)
case class AImpl(i: Int) extends A {
override type TYPE = A
override def create(i: Int) = A(i)
override def maintainedValue: Int = 2
}
}
object B {
def apply(i: Int): B = new BImpl(i)
case class BImpl(i: Int) extends B {
override type TYPE = B
override def create(i: Int): TYPE = B(i)
override def maintainedValue: Int = 1
}
}

Could not find implicit value for parameter

I've recently started learning Scala's implicit "magic" and I'm having troubles with implicit Scala objects. I've tried all the possible variants but nothing seems to work.
Lets assume I have a class like this with some solve() function. It should return 2 Float values if the input a, b were Float. Otherwise it should return another type values:
class Solver[T](val a: T, val b: T) {
def solve[A](implicit num: customNumeric[T]): Option[(T, T)] = {
Option(
num.f(num.g(a)),
num.f(num.g(b)))
}
}
Let's assume another-type-value is an object of class like this:
class MyClass[T] (x: T, y: T)(implicit num: customNumeric[T]) {
val field : T = num.f(x)
}
And let's also assume that I dont have the functions I need in basic Scala Numeric so I should make my own custom numeric.
Here is what I've done:
I've made an abstract class for my own customNumeric with my methods f() and g() and couple of implicit objects that extend my customNumeric for some value types (Int, Float for example) and implemented method in them:
abstract class customNumeric[T] {
def f(x: T): T
def g(x: T): T
}
object customNumeric {
implicit object IntIsCustomNumeric extends customNumeric[MyClass[Int]] {
def f(x: MyClass[Int]) = new MyClass[Int](x.field + 5)
def g(x: MyClass[Int]) = new MyClass[Int](x.field - 5)
}
implicit object FloatIsCustomNumeric extends customNumeric[Float] {
def f(x: Float): Float = x + 3
def g(x: Float): Float = x - 3
}
}
In my opinion Solver's solve() should use implicit customNumeric object to get implementations for methods referenced inside solve() based upon type of the Solver's input values.
But this doesn't work as compiler says:
could not find implicit value for parameter num: customNumeric[Int]
def f...
It also complains because of not enough arguments for constructor MyClass at the same line.
I've already tried making companion object to cast Int to MyClass:
object Fraction {
implicit def int2MyClass(x: Int): MyClass[Int] = new MyClass[Int](x, 1)
}
But that also doen't seem to work. And I've tried to make another implicit object to implement methods I use in customNumeric[MyClass[Int]].
Do you have any ideas? Thanks in advance!
The problem is that you're trying to define the implicit objects with classes that themselves require that same implicit object.
Meaning, this:
class MyClass[T] (x: T, y: T)(implicit num: CustomNumeric[T])
Requires an existence of an implicit CustomNumeric[T]. You cannot define IntIsCustomNumeric using that type:
implicit object IntIsCustomNumeric extends customNumeric[MyClass[Int]]
When you implement IntIsCustomNumeric, you need to implement it for type Int, not for type MyClass[Int]. When you do that, i.e:
object CustomNumeric {
implicit object IntIsCustomNumeric extends CustomNumeric[Int] {
override def f(x: Int): Int = x
override def g(x: Int): Int = x
}
}
Now, you can create an Solver[Int] which takes an implicit CustomNumeric[Int]:
def main(args: Array[String]): Unit = {
import CustomNumeric._
val solver = new Solver[Int](1, 2)
println(solver.solve)
}
Now, it's also easier to create an implicit conversion from an Int type to something that creates a MyClass[Int]:
implicit object MyClassIsCustomNumeric extends CustomNumeric[MyClass[Int]] {
override def f(x: MyClass[Int]): MyClass[Int] = new MyClass[Int](x.field + 5)
override def g(x: MyClass[Int]): MyClass[Int] = new MyClass[Int](x.field + 3)
}
implicit def intToMyClass(i: Int) = new MyClass[Int](i)
What do you think about this
object customNumeric {
implicit object IntIsCustomNumeric extends customNumeric[Int] {
def f(x: Int): Int = x + 3
def g(x: Int): Int = x - 3
}
implicit object FloatIsCustomNumeric extends customNumeric[Float] {
def f(x: Float): Float = x + 3
def g(x: Float): Float = x - 3
}
implicit def int2MyClass(x: Int): MyClass[Int] = new MyClass[Int](x, 1)
implicit object cn extends customNumeric[MyClass[Int]] {
def f(x: MyClass[Int]) = x.field + 5
def g(x: MyClass[Int]) = x.field - 5
}
}

How do I use "implicit" as apply() parameter?

I want to do this:
abstract class Context {
def getInt(id: Int): Int
}
abstract class Dependency[+T]
(val name: String, val id: Int)
extends Function1[Context,T]
class IntDependency(name: String, id: Int)
extends Dependency[Int](name, id) {
def apply(implicit context: Context): Int =
context.getInt(id)
}
But then I get an error message like this:
class IntDependency needs to be abstract, since method apply in trait
Function1 of type (v1: Context)Long is not defined (Note that T1 does
not match Context)
I understand that implicits should normally be part of the second parameter list, but I can't work out how to code it so it compiles, and gives the result I want.
Explanation: I'm trying to create a framework where one can define "Function" object, which can depend on other functions to compute their value. All functions should only take a single Context parameter. The context know the "result" of the other functions. The function instances should be immutable, with the state residing in the context. I want the functions to create "dependency" fields at creation time, which take the context implicitly, and return the value of the dependency within that context, so that accessing the dependency inside of the apply method "feels like" accessing a parameter or field, that is without explicitly giving the context as parameter to the dependency.
Are you sure you need your Dependency to extend a Function? Because if you don't, just leave the extends Function1[Context,T] part out and your code will work.
If you really need to extend a Function than I don't know of a solution in your case. But there are cases where you could try to overload the apply method. Like here:
scala> val sum = new Function1[Int, Function1[Int, Int]] {
| def apply(a: Int) = (b: Int) => a + b
| def apply(a: Int)(implicit b: Int) = a + b
|}
sum: java.lang.Object with (Int) => (Int) => Int{def apply(a:Int)(implicit b: Int): Int} = <function1>
scala> sum(2)(3)
res0: Int = 5
scala> implicit val b = 10
b: Int = 10
scala> sum(2)
res1: Int = 12
A method may have its final parameter section marked implicit; it need not be the second section, although that is most commonly seen.
But it seems that when a subclass marks a parameter section implicit, it is no longer considered to override the method in the superclass.
scala> new (Int => Int) { def apply(implicit i: Int) = i }
<console>:8: error: object creation impossible, since method apply in trait Function1 of type (v1: Int)Int is not defined
(Note that T1 does not match Int)
new (Int => Int) { def apply(implicit i: Int) = i }
^
scala> trait F1 { def f(a: Any) }; new F1 { def f(implicit a: Any) = () }
<console>:8: error: object creation impossible, since method f in trait F1 of type (a: Any)Unit is not defined
trait F1 { def f(a: Any) }; new F1 { def f(implicit a: Any) = () }
^
The spec does not specifically mention this (§5.1.4 Overriding), so it may be an implementation restriction, or an bug.
Its sure, that your apply method signature with implicit doesn´t conform with the signature of Function1.apply.
Hopefully I get your problem right, so what about (assuming that your context is mutable and perhaps singleton) having the implicit context injected at creation time? Is that possible in your case?
class IntDependency(id: Int)(implicit context: Context) extends Dependency[Int](id)
But then I wonder (and still was wondering before) what to do with the context argument at the apply method.
Here is the working solution:
abstract class Context {
def getInt(id: Int): Int
}
abstract class Dependency[+T]
(val name: String, val id: Int) {
def get(context: Context): T
}
class IntDependency(name: String, id: Int)
extends Dependency[Int](name, id) {
def get(context: Context): Int =
context.getInt(id)
}
implicit def intDep2Int(dep: IntDependency)
(implicit context: Context): Int =
dep.get(context)

Why does the compiler not look in the enclosing class for a method?

Have a look at the following Scala example:
class A {
def foo(x: Int): Int = x
private class B {
def foo(): Int = foo(3)
}
}
The compiler produces an error message when trying to compile this:
A.scala:5: error: too many arguments for method foo: ()Int
def foo(): Int = foo(3)
^
For some reason the compiler doesn't look in the enclosing class A to find the method to call. It only looks in class B, finds the foo method there that takes no parameters that doesn't fit and then gives up. If I rename the methods, then it works without a problem:
class A {
def bar(x: Int): Int = x
private class B {
def foo(): Int = bar(3)
}
}
In this case, the compiler does look in class A and finds the bar method there.
Why does the first example not work; is this according to Scala's specifications, or is this a compiler bug? If this is according to the rules, then why are the rules like this?
By the way, another way to get around the problem is by using a self type annotation:
class A {
self =>
def foo(x: Int): Int = x
private class B {
def foo(): Int = self.foo(3)
}
}
Technically the class B is a block. You could reduce the problem to the following:
def foo(x: Int): Int = x;
{
def foo(): Int = foo(3)
}
That would cause the exact same problem. It is compliant to the specs, because all names introduced in a block shadow anything that has the same name (ignoring the signature, see chapter 2 of the spec). Overloading is only possible on class level. (chapter 6.26.3 in the spec)