diff options
author | Eugene Burmako <xeno.by@gmail.com> | 2014-02-01 00:46:07 +0100 |
---|---|---|
committer | Eugene Burmako <xeno.by@gmail.com> | 2014-02-15 09:23:51 +0100 |
commit | fa8f4022754356859f3af1c4ffbac02ab3dc3e7c (patch) | |
tree | 967f7ba7625c63c7d87b0ef659afb8516c589def /test/debug | |
parent | 462d0b8b1c9de95baad773856a7e1f658ebd0956 (diff) | |
download | scala-fa8f4022754356859f3af1c4ffbac02ab3dc3e7c.tar.gz scala-fa8f4022754356859f3af1c4ffbac02ab3dc3e7c.tar.bz2 scala-fa8f4022754356859f3af1c4ffbac02ab3dc3e7c.zip |
some renamings
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.
Diffstat (limited to 'test/debug')
0 files changed, 0 insertions, 0 deletions