Idea for a new @OverloadedParam annotation

49 views
Skip to first unread message

Christian Raoulis

unread,
Oct 28, 2022, 11:55:18 AM10/28/22
to Project Lombok
Basically an Annotation which can be applied to an method parameter and takes a list of classes.

That list is used to genenerate methods that overload the original method.

Example:

This method:

private void foo(@OverloadedParam({String.class}) int bar) {
    System.out.print(bar);
}

generates:

// Source Method without annotation
private void foo(int bar) {
    System.out.print(bar);
}

// Overload of the Source Method
private void foo(String bar) {
    System.out.print(bar);
}

I got a bunch of projects where such an annotation would save me a lot time.

Thoughts?

Thanks!

Chris

Reinier Zwitserloot

unread,
Nov 12, 2022, 11:44:17 AM11/12/22
to Project Lombok
This seems useless for all cases _except_ `println`, and would result in a lot of type system fracas. The correct way to implement this is to have something like `public void foo(String | int bar) {}`  and then have the type system in general (so, not just the compiler and the compiler's type check, but also your tooling) treat the type as a disjoint combination. This actually works already: That syntax is legal in catch blocks and IDEs really do it right, they show you only methods that are available across __all__ of the types (it shows the intersection, as it should). Trying to make lombok fake javac/eclipse/intellij into treating an entire method param in that fashion is extremely convoluted. To make matters considerably worse, the existing construct (in exception catch blocks) __do not__ allow what you are doing - you can't call a method with them that has an overload for every type in the disjoint. So we have to find a way to make the IDEs use something that exists but then tweak it, or we need to implement on our own the considerable trouble of making eclipse know what disjoints are. This is well beyond what lombok ought to be doing, and would be a maintenance nightmare.

For what its worth, this also doesn't seem particularly useful, except specifically for println(), which is one of the very few methods in the core libs that has an overload for everything.

Reply all
Reply to author
Forward
0 new messages