summaryrefslogtreecommitdiff
path: root/test/files/run/reflection-magicsymbols-invoke.scala
Commit message (Collapse)AuthorAgeFilesLines
* some renamingsEugene Burmako2014-02-151-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* cleans up usages of <init>Eugene Burmako2012-12-291-1/+1
|
* Changes reflection tests to use shorter name constructorsDen Shabalin2012-12-251-1/+1
|
* turns on documentation of scala.reflect.runtimeEugene Burmako2012-10-031-1/+7
| | | | | | | | 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.
* SI-6363 removes scala.reflect.baseEugene Burmako2012-09-191-1/+1
| | | | | 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.
* SI-6178 reflective invocation of magic symbolsEugene Burmako2012-08-061-0/+94
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).