You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
public classTest {
public static void main(String[] args, int argv) {
SomeClass a =newSomeClass();
SomeClass2 a2 =newSomeClass2();
SomeClass b = a.f.set(23).f.set(23);
SomeClass2 b2 = a2.f.set(23).f.set(23);
}
}
This compiles and runs because the java compiler makes use of checkcast and NameAndType to downcast (reify so to say, it is a kind of runtime type info) the type parameter ParentType to SomeClass resp. SomeClass2. The code also looks very clean.
The scala compiler doesn't do this, although NameAndType is available)
C:\scala-2.10.0-M6\myexamples\javainterop>scalac main.scala
main.scala:11: error: value f is not a member of type parameter ParentType
var b : SomeClass = a.f.set(23).f.set(23)
^
main.scala:12: error: value f is not a member of type parameter ParentType
var b2 : SomeClass2 = a.f.set(23).f.set(23)
^
two errors found
You have to manually explicitly use implicit conversions.
I think #1377 is a bit overdone. As the above shows there are still valid use cases for checkcast (i.e. to avoid verbosity and ambiguity in the client surface code)
@paulp said:
checkcast is an implementation detail, it's not relevant to this bug - checkcast happens whenever it needs to, but if the type of something is "Any" then there's nothing to check. The bug, assuming it is one, is that the scalac classfile parser doesn't in this case find the applied type argument of an enclosing class.
see attachments for
In java client code:
This compiles and runs because the java compiler makes use of checkcast and NameAndType to downcast (reify so to say, it is a kind of runtime type info) the type parameter ParentType to SomeClass resp. SomeClass2. The code also looks very clean.
The scala compiler doesn't do this, although NameAndType is available)
You have to manually explicitly use implicit conversions.
For 1 concrete class SomeClass this works but for two and more this becomes ambiguous.
For two or more the only work around to make it compilable and runnable is:
which looks awful (this is almost an advertisement for java succinctness)
javap for java code
I think #1377 is a bit overdone. As the above shows there are still valid use cases for checkcast (i.e. to avoid verbosity and ambiguity in the client surface code)
Associated thread:
https://groups.google.com/forum/?hl=en&fromgroups#!topic/scala-user/Tl8TZ2LUsbM
The text was updated successfully, but these errors were encountered: