| 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.
|
| | |
|
| |
|
|
|
|
|
| |
This renaming arguably makes the intent of `asType` more clear,
but more importantly it shaves 6 symbols off pervasive casts that
are required to anything meaningful with reflection API
(as in mirror.reflectMethod(tpe.member(newTermName("x")).asMethodSymbol)).
|
|
|
TypeRef(ThisType(<package1>), sym, args) should always be equal to
TypeRef(ThisType(<package2>), sym, args) regardless of whether
package1 and package2 actually represent the same symbols of not.
This goes for subtyping (<:<) and type equality (=:=).
However regular equality (==) and hashconsing is unaffected
as per http://groups.google.com/group/scala-internals/browse_thread/thread/4bef4e6987bb68fe
This is done to account for the fact that mirrors share normal symbols,
but never share package symbols. Therefore at times it will occur that
the same types loaded by different mirrors appear different because of
the package symbols. More details: https://issues.scala-lang.org/browse/SI-5959.
|
