|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
Exposes a popular code pattern in macros as a dedicated reflection API.
This simple commit, however, ended up being not so simple, as it often
happens with our compiler.
When writing a test for the new API, I realized that our (pre-existing)
MethodSymbol.isPrimaryConstructor API returns nonsensical results for
implementation artifacts (trait mixin ctors, module class ctors).
What’s even more funny is that according to our reflection internals,
even Java classes have primary constructors. Well, that’s not surprising,
because `primaryConstructor` is just `decl(ctorName).alternatives.head`.
Good thing that package classes don’t have constructors or that would
elevate the situation to three fries short of a happy meal.
At the moment, I’m too scared to fiddle with internal#Symbol.primaryConstructor,
because that could easily break someone right before RC1, so I simply
documented the findings in SI-8193 and postponed the actual work, except
for one thing - isJavaDefined symbols no longer have primary constructors.
|