Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v5]

2024-04-05 Thread Pavel Rappo
On Fri, 5 Apr 2024 19:58:27 GMT, Jonathan Gibbons wrote: > > Does this make sense? > > While I am dubious about 3-tuples, your explanation makes enough sense that I > accept your reply. Thanks for the explanation. Yet another alternative notation, should we come up with one in the future. Whi

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v5]

2024-04-05 Thread Jonathan Gibbons
On Fri, 5 Apr 2024 19:47:40 GMT, Pavel Rappo wrote: > Does this make sense? While I am dubious about 3-tuples, your explanation makes enough sense that I accept your reply. Thanks for the explanation. - PR Comment: https://git.openjdk.org/jdk/pull/18519#issuecomment-2040539618

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v5]

2024-04-05 Thread Pavel Rappo
On Fri, 5 Apr 2024 17:52:25 GMT, Jonathan Gibbons wrote: > Approved, with two optional suggestions. Both could be considered style > suggestions. > > ## 1 > (Minor) While I like the new multi-valued return for > `forMember(ExecutableElement executable)` I'm slightly surprised at the use > of

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v5]

2024-04-05 Thread Jonathan Gibbons
On Fri, 5 Apr 2024 15:03:36 GMT, Pavel Rappo wrote: >> Creating a link to a constructor or a method or comparing constructors or >> methods __does not__ factor in type parameters. When constructors or methods >> are overloaded and differ only in type parameters -- a situation which is >> absen

Re: RFR: 8325088: Overloads that differ in type parameters may be lost [v5]

2024-04-05 Thread Pavel Rappo
> Creating a link to a constructor or a method or comparing constructors or > methods __does not__ factor in type parameters. When constructors or methods > are overloaded and differ only in type parameters -- a situation which is > absent in JDK API, but present elsewhere -- that causes signifi