| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the pursuit of simplicity and consistency.
- Method names like getType, getClass, and getValue are far too ambiguous,
both internally and especially with java reflection names. Methods which
accept or return scala symbols should not refer to them as "classes" in
the reflection library. (We can live with the FooClass convention for naming
the well-known symbols, it's names like "getClass" and "classToType" which
are needlessly conflationary.)
- Meaningless names like "subst" have to be expanded.
- We should hew closely to the terms which are used by scala programmers
wherever possible, thus using "thisType" to mean "C.this" can only beget confusion,
given that "thisType" doesn't mean "this.type" but what is normally called
the "self type."
- It's either "enclosing" or "encl", not both, and similar consistency issues.
- Eliminated getAnnotations.
- Removed what I could get away with from the API; would like to push
those which are presently justified as being "required for LiftCode" out of the core.
- Changed a number of AnyRefs to Any both on general principles and because
before long it may actually matter.
- There are !!!s scattered all over this commit, mostly where I think
the name could be better.
- I think we should standardize on method names like "vmSignature, vmClass" etc.
when we are talking about jvm (and ostensibly other vm) things.
There are a bunch more places to make this distinction clear (e.g.
Symbol's javaBinaryName, etc.)
- There is a lot more I want to do on this and I don't know where the
time will come from to do it.
Review by @odersky, @scalamacros.
|
