Reflection on records

[Artyom Drozdov]

If you have a way to declare the complete function type, you don't have the
overload and generic issues anymore, like it is already done for lamdas.
Maybe you are right and the first (and more important) thing would be type
safe MethodHandles.
Or maybe we could utilize something similar with the approach you suggested
before. What if we introduce Serializable-like interface, that would allow
us introspection of instance of FunctionalInterface?

Runnable hello = (Runnable & Introspectable)Foo::hello;

This allows us to deduct the signature (as we already do) and have extra
runtime information via Introspectable interface, that could contain
reflective information, like method name, argument types, etc.

пн, 1 дек. 2025 г., 20:53 Attila Kelemen <attila.kelemen85 at gmail.com>:

> 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 <artyomcool2 at gmail.com> 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 <attila.kelemen85 at gmail.com>:
>>
>>> 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 <artyomcool2 at gmail.com> 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.
>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20251201/47923360/attachment-0001.htm>