-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Restore some form of Reflection.Type.apply(clazz: Class[_]) #9850
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
Comments
Are you aware that the method that existed before is unsound, as it only works for classes that do not have any type parameters? If yes, why was that not an issue in your application? |
I was aware. My use case needs to marshal a Type from the class. My library creates high level abstractions of the low-level reflected type information, which involves identifying and resolving the type parameters. Specifically, in my nomenclature, Short answer: you’re right, this call can’t successfully marshal a complete parameterized Type from a class by itself, but it can be used with an ancestor (parameterized) reference type to build the complete picture. If there is some other way to construct a Type from a class, I’m open to that, and understand that type parameters are my problem. Aside from that shortcoming, the Type is usful to obtain all the other information we need to learn from the class. |
That is still not possible in cases like trait SomeTrait[A]
class AClass[A, B] extends SomeTrait[A] The only thing you're ever able to recover is @nicolasstucki Is a |
Yes, |
Then perhaps we could reintroduce this feature but with a more explicit name like WDYT? Would that make sense? |
It looks ok to me. I will open a PR for it. |
sjrd: Yes if your reference trait doesn’t define all if the class’ parameters, as in your example, then those params left undefined will remain in the class as a type symbol in my system with an actual type of Any—they won’t resolve. This actually makes sense—the caller didn’t specify, and if the reference trait is “narrower” than the class, perhaps that’s all the caller needed, but that’s their responsibility. |
And I’m great with a more descriptive name. There’s a pr open for this, so if you guys agree on a new name, I can change it in Reflection and with your blessing merge the code. Let me know if you also want to mirror the new name in CompilerInterface or leave the one that’s already there. |
You can change the definition in |
ok, shall I use the existing name, ofErasedClass? That’s what’s in the pr now. |
|
Uh oh!
There was an error while loading. Please reload this page.
This method was removed roughly 7 days ago with a commit.
I used this to create a Type as a bridge between Tasty Inspection and Reflection. In my Inspection code I called Type.apply(clazz) then used the Type in the same code I share with Reflection.
I see the commit provided Type.ofErasedClass(clazz: Class[_]) in the CompilerInterface but didn't expose it in Reflection.
Please expose ofErasedClass() in Reflection.
This change did break my application code with no clear workaround.
The text was updated successfully, but these errors were encountered: