You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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.
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.
The text was updated successfully, but these errors were encountered: