Also, by the way, these method literals have limited usefulness, if you just declare them `Method` or `MethodHandle`, because sure the compiler can check the method name, but it won't be able to check for the number of parameters and their type, and so sure, a little better, but not that much. If method literals (etc) would be a thing, then I would expect arbitrary function types with them as well (which could have a common base of course). Like `function<long(String, int)>`, and in this case, accepting the raw type becomes a lot more problematic, because returning `Object.class` when a declaration clearly states `String` is a bit troubling (for me it is for sure).
Artyom Drozdov <[email protected]> ezt írta (időpont: 2025. dec. 1., H, 20:35): > 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. >>> >>>> >>>>
