Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get rid of pervasive casts in the reflection API #8220

Closed
scabug opened this issue Feb 1, 2014 · 3 comments
Closed

Get rid of pervasive casts in the reflection API #8220

scabug opened this issue Feb 1, 2014 · 3 comments
Milestone

Comments

@scabug
Copy link

scabug commented Feb 1, 2014

At the moment, reflection code is very often plagued by casts. Not those brutal and obvious asInstanceOf's, but rather the sneaky asXXX methods on symbols.

Got a method from a list of members and want to figure out its return type - do a cast. Got a class from Type.typeSymbol and want to check out its type params - do a cast. And so on, and so forth.

This has to stop.

@scabug
Copy link
Author

scabug commented Feb 1, 2014

Imported From: https://issues.scala-lang.org/browse/SI-8220?orig=1
Reporter: @xeno-by
Affected Versions: 2.10.0, 2.11.0
Blocks #8189

@scabug
Copy link
Author

scabug commented Feb 1, 2014

@xeno-by said:
The most plausible idea I know of at the moment implies introduction of specialized methods on types: Type.methods, Type.field, Type.typeMembers, etc. This, combined with having NoSymbol conform to all symbol flavors will provide statically-typed signatures for typical reflection tasks.

This, by the way, is going to require us to rethink our classification of symbols within the reflection API in order to be consistent with the language we're reflecting against, not with internal implementation details of a compiler for that language. In particular, we're going to need things like FieldSymbols and TypeMemberSymbols, and maybe even dedicated symbol classes for value and type parameters.

@scabug scabug added the blocker label Apr 7, 2017
@scabug scabug added this to the Backlog milestone Apr 7, 2017
@SethTisue SethTisue removed the blocker label Jul 19, 2017
@SethTisue
Copy link
Member

the Scala 2 reflection API is highly unlikely to undergo any sweeping changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants