Reflection on records

[Attila Kelemen]

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/7385a404/attachment.htm>