Why does this code throw an exception?
val x = new { def toInt(n: Int) = n*2 }
x.toInt(2)
scala.tools.nsc.symtab.Types$TypeError: too many arguments for method toInteger: (x$1: java.lang.Object)java.lang.Integer
at scala.tools.nsc.typechecker.Contexts$Context.error(Contexts.scala:298)
at scala.tools.nsc.typechecker.Infer$Inferencer.error(Infer.scala:207)
at scala.tools.nsc.typechecker.Infer$Inferencer.errorTree(Infer.scala:211)
at scala.tools.nsc.typechecker.Typers$Typer.tryNamesDefaults$1(Typers.scala:2350)
...
I'm using scala 2.9.1.final
Clearly a compiler bug (the compiler crashes, and REPL tells you That entry seems to have slain the compiler.). It's not signalling there's anything wrong with your code.
You're creating a single instance of type AnyRef{def toInt(n: Int): Int}, so creating a singleton object as Kyle suggests might be a better way of going about it. Or create a named class / trait that you insantiate, which works fine.
EDIT: As Luigi Plinge suggested, it's a compiler bug.
Maybe you want something like this...
object x {
def toInt(n:Int) = n * 2
}
scala> x.toInt(2)
res0: Int = 4
Related
I can't comprehend why the compiler allows for the current code.
I use phantom types to protect access to methods. Only under specific "states" should methods be allowed to be called.
In most scenarios, this invariant is indeed verified by the compilation. Sometimes however, the compiler just ignores the constraint imposed by the phantom type.
This feels like a major bug. What am I not understanding?
I tried to simplify the problem as much as possible. My use case is more complex:
class Door[State <: DoorState] private {
def doorKey: Int = 1
def open[Phatom >: State <: Closed.type]: Door[Open.type] = new Door[Open.type]
def close[Phatom >: State <: Open.type]: Door[Closed.type] = new Door[Closed.type]
}
object Door {
def applyOpenDoor: Door[Open.type] = new Door[Open.type]
def applyClosedDoor: Door[Closed.type] = new Door[Closed.type]
}
sealed trait DoorState
case object Closed extends DoorState
case object Open extends DoorState
Then
val aClosedDoor = Door.applyClosedDoor
val res1 = aClosedDoor.close // does not compile. Good!
val res2 = aClosedDoor.open.close.close // does not compile. Good!
println(aClosedDoor.open.close.close) // does not compile. Good!
println(aClosedDoor.open.close.close.doorKey) // does not compile. Good!
aClosedDoor.open.close.close.doorKey == 1 // does not compile. Good!
println(aClosedDoor.open.close.close.doorKey == 1) // compiles! WTF?
As you can see above, the client can close a closed door. In my library, the corresponding behaviour is throwing a runtime exception. (I was confident the exception was well protected and impossible to reach)
I have only been able to replicate this problem for expressions returning boolean and when this is the argument to a function (in the example, println)
I am not looking for alternative solutions as much as I am looking for an explanation as to how this can happen? Don't you agree this is a considerable flaw? Or maybe I am missing something?
Scala version: 2.13.5
Edit
After a discussion on gitter, I opened bug request # https://github.com/scala/bug
The problem does not seem to occur in scala 3.
Seems it is an bug related to usage of nullary method
def doorKey: Int = 1
if instead it is defined as nilary method
def doorKey(): Int = 1
then it works as expected
println(aClosedDoor.open.close.close.doorKey() == 1) // compiler error
I have the following snippet that (I think) defines a method addNumber1(x:T):T on a generic type T which is a subtype of AnyVal and has a method +(s:Int):T.
def addNumber1[T <: AnyVal {def +(s:Int):T}](x:T):T = {x + 1}
addNumber1(31) // compiles but throws exception
java.lang.NoSuchMethodException: java.lang.Integer.$plus(int)
at java.lang.Class.getMethod(Class.java:1786)
at .reflMethod$Method1(<console>:8)
at .addNumber1(<console>:8)
... 33 elided
I tried adding import scala.language.reflectiveCalls to suppress a feature warning but still get the error.
I am able to use this when working with AnyRef or Any as below:
def addNumber1[T <: Any {def +(s:Int):T}](x:T):T = {x + 1}
class Foo(s:String) {def +(i:Int) = new Foo((s+1).toString)} // random code
class Bar(s:Foo) {def +(i:Int) = new Bar(new Foo(i.toString))} // random code
addNumber1(new Foo("1")) // works
addNumber1(new Bar(new Foo("1"))) // works
addNumber1(1) // compiles but gives exception
You run into an intersection of quite a few features:
So far as the initial stages of Scala compiler are concerned (including typechecking), Int does have an (overloaded) + method. But this "method" is treated specially by the later stages (as are all methods on Int, because it isn't really a class).
Methods called + and defined in Scala are translated to methods called $plus in bytecode, since + is not a legal identifier there. Since + on Int is special, as mentioned above, this doesn't apply to it. Since the structural types are implemented using Java reflection, your addNumber1 looks somewhat like
def addNumber1(x: Object) = x.getClass.getMethod("$plus").invoke(x, 1)
To call addNumber1 on an int, it has to be boxed to Integer first, because int is not an object. Integer, not being a Scala type, doesn't have a $plus method. In Scala you can write something like val x: Integer = ...; x + 1, but this uses an implicit conversion which Java reflection has no idea about.
I think the problem has nothing to do with AnyVal, AnyRef Or Any.
addNumber1(new Foo("1"))
This works because you indeed defined a Foo class that provides an implementation of def +(s:Int):T.
addNumber1(1)
This doesn't work because Integer class doesn't provide it, as is mentioned in the exception:
java.lang.NoSuchMethodException: java.lang.Integer.$plus(int)
In Scala what is the correct way to implement something like this that produces the error "forward reference extends over definition of value b"?
object a {
def main(args: Array[String]) {
val b: Map[Int, () => Int] = Map(5 -> { () => b.size })
println(b(5)())
}
}
Making b lazy works but that doesn't seem like the correct solution.
EDIT: The other question (What does "Forward reference extends over definition of value" mean in Scala?) is about a bug in Scala itself that where this error is reported incorrectly (or that is what the accepted answer suggests). This question is about what to do when this error is reported correctly. Also I supplied sample code.
Making b lazy seems like overkill because it changes the run-time behavior, when this is a compile-time problem that I assume could be fixed with a different declaration...
As mentioned in the comments, making b a def works too, which seems closer to the solution since def works for recursive functions, but that seems to be reevaluating it at run-time every time it is accessed.
scala> var a = 5
scala> def b = a
scala> a = 2
scala> b
res0: Int = 2
scala> a = 1
scala> b
res1: Int = 1
(with lazy it can be changed before it is accessed but is stored after that)
Both of these seem like run-time solutions to a compile-time problem, I'm looking for something analogous to letrec in Scala.
When you define a non-lazy val, you cannot refer to that val inside its definition. For that you either have to use a def or a lazy val.
This example code is based on Atmosphere classes, but if someone could give me some insights into what the error means in general, I think I can figure out any Atmosphere-specific solution...
val bc = BroadcasterFactory.getDefault().lookup(_broadcasterId)
bc.broadcast(message)
After the first line, bc should contain a handle to an object whose class definition includes the method broadcast() -- in fact, it contains several overloaded variations. However, the compiler chokes on the second line of code with the following: "value broadcast is not a member of Nothing"
Any ideas/suggestions on what would be causing this?
Thanks.
EDIT: signature for [BroadcasterFactor].lookup :
abstract Broadcaster lookup(Object id)
Note: 1) that is the signature version that I've used in the example, 2) it is the java Inteface signature - whereas the getDefault() hands back an instantiated object that implements that interface.
Solution: force type cast on value:
val bc: Broadcaster = BroadcasterFactory.getDefault().lookup(_broadcasterId)
Nothing is the type name. It's the subtype of all other types. You can't call methods from Nothing itself, you have to specify exact type ((bc: ExactType).broadcast(message)). Nothing has no instances. Method, that returns Nothing will, actually, never return value. It will throw an exception eventually.
Type inference
Definition of lookup:
abstract public <T extends Broadcaster> T lookup(Object id);
in scala this definition looks this way:
def lookup[T <: Broadcaster](Object id): T
There is not specified type parameter in lookup method. In this case compiler will infer this type parameter as the most specific type - Nothing:
scala> def test[T](i: Int): T = ???
test: [T](i: Int)T
scala> lazy val x = test(1)
x: Nothing = <lazy>
scala> lazy val x = test[String](1)
x: String = <lazy>
You could specify type parameter like this:
val bc = BroadcasterFactory.getDefault().lookup[Broadcaster](_broadcasterId)
Draft implementation
In development process lookup can be "implemented" like this:
def lookup(...) = ???
??? returns Nothing.
You should specify either result type of lookup method like this: def lookup(...): <TypeHere> = ... or type of bc: val bc: <TypeHere> =.
The toInt method in StringLike doesn't take any arguments, and can only parse in decimal. So to parse binary, hex etc we need to resort to Java's Integer#parseInt(String s, int radix).
In an attempt to remedy this state of affairs, I tried the following
implicit def strToToIntable(s: String) = new {
def toInt(n: Int) = Integer.parseInt(s, n)
}
However,
"101".toInt(2)
causes the REPL compiler to "crash spectacularly" and doesn't work in compiled code either.
Is there some restriction on overloading existing methods using the "enrich my library" pattern?
Without the implicit, running "101".toInt(2) causes REPL to tell me that Int does not take parameters. So I guess what is happening is that it's running "101".toInt, then trying to call apply(2) on that, which doesn't make sense. I'd suggest a subtle rename of your pimped toInt to avoid the problem.
edit
I just had some success of my own. I explicitly defined a pimped string class as
class StrToRadixInt(s:String) {
def toInt(radix: Int) = Integer.parseInt(s,radix)
}
implicit def strToToIntable(s:String) = new StrToRadixInt(s)
And REPL was happy:
scala> "101".toInt(2)
res4: Int = 5
The REPL shouldn't crash--that's a bug. But even so, overloading of names is somewhat discouraged and also not supported in some contexts. Just use a different name:
implicit def parseBase(s: String) = new { def base(b: Int) = Integer.parseInt(s,b) }
scala> "10110" base 2
res1: Int = 22