|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** Important note for busy commit log skimmers ***
Symbol method "fullName" has been trying to serve the dual role of "how
to print a symbol" and "how to find a class file." It cannot serve both
these roles simultaneously, primarily because of package objects but
other little things as well. Since in the majority of situations we want
the one which corresponds to the idealized scala world, not the grubby
bytecode, I went with that for fullName. When you require the path to a
class (e.g. you are calling Class.forName) you should use javaClassName.
package foo { package object bar { class Bippy } }
If sym is Bippy's symbol, then
sym.fullName == foo.bar.Bippy
sym.javaClassName == foo.bar.package.Bippy
*** End important note ***
There are many situations where we (until now) forewent revealing
everything we knew about a type mismatch. For instance, this isn't very
helpful of scalac (at least in those more common cases where you didn't
define type X on the previous repl line.)
scala> type X = Int
defined type alias X
scala> def f(x: X): Byte = x
<console>:8: error: type mismatch;
found : X
required: Byte
def f(x: X): Byte = x
^
Now it says:
found : X
(which expands to) Int
required: Byte
def f(x: X): Byte = x
^
In addition I rearchitected a number of methods involving:
- finding a symbol's owner
- calculating a symbol's name
- determining whether to print a prefix
No review.
|
|
Various and sundry manipulations to allow for objects to be overridden
when the mood is right. It is not enabled by default.
The major contributor of change turned out to be the decoupling of
the FINAL flag (and the "isFinal" test which examines only that flag)
and the many semantics which were attributed to this interpretation
of finality in different circumstances. Since objects no longer have
the FINAL flag automatically applied (only top-level objects and those
marked final in source code do) we need apply a more nuanced test.
Fortunately there is such a nuanced test: isEffectivelyFinal,
which is always true if the FINAL flag is set but also in various
other circumstances. In almost every case, you should be testing
"isEffectivelyFinal", not "isFinal".
To enable overridable objects, use:
-Yoverride-objects
-Xexperimental // includes the above and others
Remain to be done: working out transition logistics. Most likely this
would involve bumping the scala signature version, and all objects in
versions before that would be assumed final.
Review by moors.
|