expose much needed methods in public reflection/macro API

[scabug]

Ideally we should be able to write scala-async / sbt macros without resorting to down casting.

• expose the current owner of the call site typer
• conveniences like paramss, typeArgs, resultType, finalResultType
• more to come

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-8063?orig=1
Reporter: @retronym
Affected Versions: 2.10.3
See #6732, #6441, #8118, #6379, #6565, #6733, #6814, #7044, #8086, #6931, #6785, #7993, #7533

[scabug]

@xeno-by said:
http://stackoverflow.com/questions/20417654/consructing-or-modifying-scala-reflect-api-position

[scabug]

@soc said:
Can we get a better name for paramss at least in the public API? If people want to have their maximally cryptic abbreviations in the compiler, I don't care, but we shouldn't start exposing them to users.

[scabug]

@densh said:
equalsStructure vs structureEquals on trees. I don't care which one stays but it's really crazy that we have both

[scabug]

@xeno-by said:
I will add a couple related issues while I go through the list triaging bugs.

[scabug]

@densh said:
Another point is change of api on FunctionClass, TupleClass and ProductClass. Currently they are exposed as a Int => Symbol. Currently it's hard to find if symbol is a Function, Tuple or Product. We either need to expose seq extra field or provide additional helper methods.

[scabug]

@xeno-by said (edited on Dec 19, 2013 10:17:01 PM UTC):
We should also go through the APIs and apply deprecation to things that seemed to be useful, but ended up unused (deSkolemize, I'm looking at you!).

[scabug]

@xeno-by said:
https://groups.google.com/forum/#!topic/scala-internals/CfmPHXrHliw

[scabug]

@xeno-by said:
How about we also tackle the NoSymbol <: XXXSymbol problem, so that we can formulate convenient methods called method, methods, etc?

[scabug]

@xeno-by said:
http://stackoverflow.com/questions/20908036/how-do-i-splice-symbols-of-various-types-in-a-quasiquote

[scabug]

@xeno-by said (edited on Jan 4, 2014 7:01:50 AM UTC):
Also, if we don't manage to fix the NoSymbol problem, at least there are some places in the API where we can improve the types of returned values (e.g. MethodSymbol.typeParams, MethodSymbol.paramss, etc).

[scabug]

@xeno-by said:
Also, it looks like TermSymbol doesn't refine name to be TermName, same for TypeSymbol. Not good.

[scabug]

@clhodapp said:
To Simon's point, how about 'paramLists' instead of 'paramss'?

[scabug]

@xeno-by said:
Would also be nice to add ClassSymbol.primaryConstructor.

[scabug]

@xeno-by said:
@chris Hodapp. Not sure about the names yet. First I'd like to figure out the list of methods to add/remove.