Reducing verbosity for generics

[Olexandr Rotan]

If I were to propose the solution, I would make implementation of methods
that return this.class uninheritable if its parent impl not returns
this.class type, i.e. each subtype obliged to redefine method unless it's
parent delegates return to a method that returns this.class itself.
Effectively this would mean that each type must redefine end of each chain
of methods that return this.class. This would reduce inheritence effort to
effectively having to override 1 (in good design) supplier method and still
allow to inherit actual logic from super classes.

Although, I must say that implementing such feature would be a headache for
sure. You must account all corner cases if adopting approach I described,
because, at least to me, it seems a bit shaky.

Also, I am not sure that complexity of this approach really justified by
solved problem. I feel like, whatever you can come up with, it is either
incredibly complex or not very effective at solving described problems

On Tue, Jun 11, 2024, 00:05 Johannes Spangenberg <
johannes.spangenberg at hotmail.de> wrote:

> and any implementation of withFoo() would just have to return an object
> with type compatible with Builder<T>.
>
> With these rules, the compiler would allow the following code, although it
> is broken:
>
> public class Builder { // May have sub-types
>     ...
>     this.class copy() {
>         return new Builder(this);
>     }
>     ...
> }
>
> Anyway, there are probably solutions to make it work in most situations
> using more elaborate rules for the type system. I guess you could also
> argue that it is OK that the compiler cannot detect the broken code above,
> and the application should just throw a ClassCastException. After all, it
> wouldn't be the only case where broken code is not detect at compile time.
> However, I think such change would require careful consideration of
> different solutions to the problem (and whether the problem justifies
> special syntax and rules).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240611/9e0b0f66/attachment.htm>