Imported From: https://issues.scala-lang.org/browse/SI-4696?orig=1
Reporter: Richard Emberson (rmemberson)
Affected Versions: 2.9.1

@paulp said:
That implementation is inadequate. How about this.

https://github.com/paulp/scala-dev/tree/runtime-class

Richard Emberson (rmemberson) said:
Looks great. I generally work off the svn head. Will this be checked in
soon?
I expect that there is a lot of code out there where folks used
solutions that were only partially baked (like mine). Letting folks
know that this exists will be very useful.
Thanks

@paulp said:
Checkin time if ever is up to martin.

@adriaanm said:
sounds good, but could we just call it getClass?

@SethTisue said:
duplicate of SI-490?

@paulp said:
I went on a multi-hour side trip after trying to reply to adriaan and discovering that JIRA has no mechanism for such a thing. It's an append-only roll of papyrus.

HEY ADRIAAN, IF YOU CAN HEAR ME UP THERE EVEN THOUGH SETH IS STANDING BETWEEN US, WE CAN'T CALL IT GETCLASS UNLESS YOU MEAN REPLACING THE JAVA.LANG.OBJECT GETCLASS. I'M NOT SURE THAT'S EITHER POSSIBLE OR WISE. PUTTING IT IN PREDEF IS NOT RIGHT IN MY OPINION, IT SHOULD BE A METHOD ON "RICHCLASS". AND THEN OF COURSE IT CAN'T BE CALLED GETCLASS BECAUSE EVERYONE ALREADY HAS THAT METHOD.

@adriaanm said:
Sorry, I should have added that it sounds like we could just pull the rug from under the old getClass's feet and replace calls to it by calls to our runtimeClass, which is like a getClass2.0, and which could thus be called thusly (without the version number). It only adds new behaviour (for AnyVal) and better typing right?

@adriaanm said:
Oh and I should also have mentioned that we=compiler and that special casing it was Martin's idea, saying it's okay because we already treat classOf special anyway

PS: DO YOU READ ME?

@paulp said:
LOUD AND CLEAR, AGENT DOT-COQ.

@SethTisue said:
If Scala was already matching the Java behavior, and we wanted to do better, then maybe a new name would be needed. But currently getClass in Scala sucks compared to getClass in Java. If all we want is to bring lame Scala up to awesome Java's level, then it should be fine to just call it getClass, yes?

In Java 6 "The actual result type is Class<? extends |X|> where |X| is the erasure of the static type of the expression on which getClass is called." See #490.

@ijuma said:
Worth saying that Paul's branch does more than bring it up to Java's level, it also handles primitives in a nicer way.

@odersky said:
Yes, but since getClass in Java does not work on primitives (correct me if I'm wrong here), we are free to do whatever we like for them.

@paulp said:
No, you're right. I implemented it in userspace only because I thought that's what I could get away with. Last night I implemented the value part directly on AnyVal, works like a charm.

@ijuma said:
Yes, in Java you have to say Integer.TYPE to get the class for the int primitive. Another situation where Scala will be more consistent. :)

Commit Message Bot (anonymous) said:
(extempore in r25137) A total rewrite of "runtimeClass", discarding the user-space
approach in favor of simply fixing getClass.

def f1 = 5.getClass // Class[Int]
def f2 = (5: AnyVal).getClass // Class[_ <: AnyVal]
def f3 = (5: java.lang.Integer).getClass // Class[_ <: java.lang.Integer]

class A
class B extends A

def f1 = (new B: Any).getClass().newInstance() // Any
def f2 = (new B: AnyRef).getClass().newInstance() // AnyRef
def f3 = (new B: A).getClass().newInstance() // A
def f4 = (new B: B).getClass().newInstance() // B

But that's not all!

def f0[T >: B] = (new B: T).getClass().newInstance()

def f5 = f0[Any] // Any
def f6 = f0[AnyRef] // AnyRef
def f7 = f0[A] // A
def f8 = f0[B] // B

Closes #490, #896, #4696. Review by moors. (Note: I think this is
pretty good, but picky review requested.)