Yes, it sounds like an issue without good solution. For me sounds ok for your example having just raw types:
Method hello = Foo::hello[Object]; But I understand it could be non-intuitive for most users. Another approach would be to allow your notation: Method hello = Foo<T>::hello[T]; But disallow specifying types like: Method helloString = Foo<String>::hello[String]; пн, 1 дек. 2025 г., 20:21 Attila Kelemen <[email protected]>: > One thing I can think of is that generics makes life a hell here, and can > spawn a lot of reasonable questions with non-obvious answers (especially if > you still believe in reified generics in the future, and try to prepare for > it). > > So, if you have > > ``` > interface Foo<T> { String hello(T a); } > ``` > > Then if you write (in your notation): `Foo<T>::hello[T]`, where T is a > type argument, then you have to return `Object.class` as the parameter type. > > However, if you have `Foo<String>::hello[String]`, then one could > reasonably expect it to return `String.class` as the parameter type, but > doing so would also be strange, because the actual type (queried via > reflection) would be `Object.class`. > > Not to mention that `hello` can be overloaded with a concrete type, but I > guess that is a theoretical problem even in today's Java. > > Attila > > > Artyom Drozdov <[email protected]> ezt írta (időpont: 2025. dec. 1., > H, 19:59): > >> Symbolic reflective constants is a something I was always dreamed about. >> I'm currently using old-but-gold CLDC HI for my pet project and I'm >> really struggling without class literals (so I'll probably add them). >> The same way I feel about fields/methods references. I suppose it was >> discussed before, but it would be great to know, why can't we ask user for >> the full signature? Like: >> >> Method m = Foo::method[String, int]; >> >> Or even (argument names here is an optional hint for the reader and >> IDE/linters): >> >> Method m = Foo::method[String name, int size]; >> >> Of course, the syntax is not something that really worth to discuss here. >> Probably, we might want to specify the return type as well, but, again, >> that's about syntax. >> >>> >>>
