Note: We cannot have same named methods defined in Object and Any (and AnyVal, for that matter) because after erasure the Any and AnyVal references get remapped to the Object methods which would result in a double binding assertion failure.
Note: We cannot have same named methods defined in Object and Any (and AnyVal, for that matter) because after erasure the Any and AnyVal references get remapped to the Object methods which would result in a double binding assertion failure. Instead we do the following:
There's a remaining question about getClass
. In Scala2.x getClass
was handled by compiler magic.
This is deemed too cumersome for Dotty and therefore right now getClass
gets no special treatment;
it's just a method on Any
which returns the raw type java.lang.Class
. An alternative
way to get better getClass
typing would be to treat getClass
as a method of a generic
decorator which gets remapped in a later phase to Object#getClass. Then we could give it
the right type without changing the typechecker:
implicit class AnyGetClass[T](val x: T) extends AnyVal { def getClass: java.lang.Class[T] = ??? }
The enumeration type, goven a value of the enumeration
An extractor for multi-dimensional arrays.
An extractor for multi-dimensional arrays. Note that this will also extract the high bound if an element type is a wildcard. E.g.
Array[_ <: Array[_ <: Number]]
would match
MultiArrayOf(<Number>, 2)
A package in which we can place all methods that are interpreted specially by the compiler
Modules whose members are in the default namespace and their module classes
The type of the boxed class corresponding to primitive value type tp
.
Dummy method needed by elimByName
If type ref
refers to a class in the scala package, its name, otherwise EmptyTypeName
If cls
is a class in the scala package, its name, otherwise EmptyTypeName
Lists core classes that don't have underlying bytecode, but are synthesized on-the-fly in every reflection universe
Lists core methods that don't have underlying bytecode, but are synthesized on-the-fly in every reflection universe
Method representing a throw
A class defining symbols and types of standard definitions
Note: There's a much nicer design possible once we have implicit functions. The idea is explored to some degree in branch wip-definitions (#929): Instead of a type and a separate symbol definition, we produce in one line an implicit function from Context to Symbol, and possibly also the corresponding type. This cuts down on all the duplication encountered here.
wip-definitions tries to do the same with an implicit conversion from a SymbolPerRun type to a symbol type. The problem with that is universal equality. Comparisons will not trigger the conversion and will therefore likely return false results.
So the branch is put on hold, until we have implicit functions, which will always automatically be dereferenced.