| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It’s almost 1am, so I’m only scratching the surface, mechanistically
applying the renames that I’ve written down in my notebook:
* typeSignature => info
* declarations => decls
* nme/tpnme => termNames/typeNames
* paramss => paramLists
* allOverriddenSymbols => overrides
Some explanation is in order so that I don’t get crucified :)
1) No information loss happens when abbreviating `typeSignature` and `declarations`.
We already have contractions in a number of our public APIs (e.g. `typeParams`),
and I think it’s fine to shorten words as long as people can understand
the shortened versions without a background in scalac.
2) I agree with Simon that `nme` and `tpnme` are cryptic. I think it would
be thoughtful of us to provide newcomers with better names. To offset
the increase in mouthfulness, I’ve moved `MethodSymbol.isConstructor`
to `Symbol.isConstructor`, which covers the most popular use case for nme’s.
3) I also agree that putting `paramss` is a lot to ask of our users.
The double-“s” convention is very neat, but let’s admit that it’s just
weird for the newcomers. I think `paramLists` is a good compromise here.
4) `allOverriddenSymbols` is my personal complaint. I think it’s a mouthful
and a shorter name would be a much better fit for the public API.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
We definitely need to document scala.reflect.runtime.universe,
therefore adding scala.reflect.runtime to skipPackages was a mistake.
But then we need to make a bunch of internal classes private to reflect
or to scala. Not very pretty, but it works.
|
|
|
|
|
| |
As the experience has shown, there's no need for a separate layer of reflection
in scala-library.jar. Therefore I'm putting an end to it.
|
|
In Scala there are some methods that only exist in symbol tables,
but don't have corresponding method entries in Java class files.
To the best of my knowledge, these methods can be subdivided into five groups:
1) stuff weaved onto Any, AnyVal and AnyRef (aka Object),
2) magic methods that Scala exposes to fix Java arrays,
3) magic methods declared on Scala primitive value classes,
4) compile-time methods (such as classOf and all kinds of macros),
5) miscellaneous stuff (currently only String_+).
To support these magic symbols, I've modified the `checkMemberOf` validator
to special case Any/AnyVal/AnyRef methods and adjusted MethodMirror and
ConstructorMirror classes to use special invokers for those instead of
relying on Java reflection.
Support for value classes will arrive in the subsequent commit, because
it requires some unrelated changes to the mirror API (currently mirrors
only support AnyRefs as their targets).
|