Community
Participate
Working Groups
Created attachment 287828 [details] Screenshot I think it would be nicer if the lambda variable name would use the regular naming convention, e.g. using the Type. See screenshot.In this example invoice should be used instead of t.
(In reply to Lars Vogel from comment #0) > Created attachment 287828 [details] > Screenshot > > I think it would be nicer if the lambda variable name would use the regular > naming convention, e.g. using the Type. > > See screenshot.In this example invoice should be used instead of t. Today we use variable name of the functional interface. But what about primitive and primitive wrappers ? I think naming based type might be useful for non-primitive and non-wrapper types. WDYT ?
(In reply to Gayan Perera from comment #1) > (In reply to Lars Vogel from comment #0) > > Created attachment 287828 [details] > > Screenshot > > > > I think it would be nicer if the lambda variable name would use the regular > > naming convention, e.g. using the Type. > > > > See screenshot.In this example invoice should be used instead of t. > > Today we use variable name of the functional interface. But what about > primitive and primitive wrappers ? I think naming based type might be useful > for non-primitive and non-wrapper types. WDYT ? +1, sounds good to me
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/192163
The assumption that all parameter names will not be meaningful is not correct, IMO. If someone names the lambda method parameter as "subject" instead of "t", we will no longer be proposing the name intended by the API provider. Consider these example: interface MyInterface<T> { void accept(T subject); } private void forEach(MyInterface<Invoice> in) {} (or) private void forEach(MyInterface<?> in) {} With the patch, I get "Invoice invoice" or "Object object" Before the patch, I get "Invoice subject" or "Object subject" I am not sure if we really want to override a given name by something else. Also consider the fact that we will be inconsistent with the code we generate when we convert an anonymous with lambda.
(In reply to Jay Arthanareeswaran from comment #4) > The assumption that all parameter names will not be meaningful is not > correct, IMO. If someone names the lambda method parameter as "subject" > instead of "t", we will no longer be proposing the name intended by the API > provider. > > Consider these example: > > interface MyInterface<T> { > void accept(T subject); > } > private void forEach(MyInterface<Invoice> in) {} > (or) > private void forEach(MyInterface<?> in) {} > > > With the patch, I get "Invoice invoice" or "Object object" > Before the patch, I get "Invoice subject" or "Object subject" > > I am not sure if we really want to override a given name by something else. > > Also consider the fact that we will be inconsistent with the code we > generate when we convert an anonymous with lambda. Yes @Jay, i had the same concern after using this patch on some of the own code. For example when i was using this on a more fine grained functional interface like a interceptor where i have given a proper name into. I'm open for suggestions if we can improve this further without making things more complex and ambiguous.
@Jay what if we do this only for java.util.function Functional interfaces which are known to be general purpose use.
@Jay i implemented my suggestion, please check how it feels now. I got some inspiration from IJ.
@Gayan, is your change *replacing* the existing naming strategy? It seems that the lambda-proposal uses linked mode after insertion. Can you offer additional heuristics as alternatives in linked mode? Since there's no one strategy that fits all, presenting alternatives would feel natural to me. Disclaimer: I failed to pull your change because EGit reported: SshException: No more authentication methods available
(In reply to Gayan Perera from comment #7) > @Jay i implemented my suggestion, please check how it feels now. I got some > inspiration from IJ. Looks much better to me now. I like how we even take care of the case like below: void accept(T t, double value) to which we propose "object, value". However, for the ToDoubleBiFunction#applyAsDouble(T t, U u), we are proposing "object, u". Looks like, within java.util.function.*, there are lot of cases to take care of.
I found the issue, its a code mistake in using wrong index in my new code. I will fix and will also try to capture the type variables so the parameters could be much meaningful
(In reply to Jay Arthanareeswaran from comment #9) > (In reply to Gayan Perera from comment #7) > > @Jay i implemented my suggestion, please check how it feels now. I got some > > inspiration from IJ. > > Looks much better to me now. I like how we even take care of the case like > below: > > void accept(T t, double value) > > to which we propose "object, value". > > However, for the ToDoubleBiFunction#applyAsDouble(T t, U u), we are > proposing "object, u". > > Looks like, within java.util.function.*, there are lot of cases to take care > of. The latest patch set fixes the issue you mentioned. But in cases where we need to resolve the type variable from the previouse argument such as in java.util.stream.Stream.reduce(Object, BiFunction<Object, ? super BigDecimal, Object>, BinaryOperator<Object>) I couldn't find a way to resolve the type variables in BiFunction from the first argument of the reduce method. Also let me know what you think about handling String and Object type parameters, May be we can exclude them as well.
(In reply to Stephan Herrmann from comment #8) > @Gayan, is your change *replacing* the existing naming strategy? Yes we change the orignal naming strategy if we can find a better variable name. And that is only done for java.util.function.* functional interfaces. > > It seems that the lambda-proposal uses linked mode after insertion. Can you > offer additional heuristics as alternatives in linked mode? Since there's no > one strategy that fits all, presenting alternatives would feel natural to me. > yes we could do that, but then the user needs to always select the parameter from the list where we suggest the original and computed isn't it ?
(In reply to Gayan Perera from comment #12) > (In reply to Stephan Herrmann from comment #8) > > @Gayan, is your change *replacing* the existing naming strategy? > > Yes we change the orignal naming strategy if we can find a better variable > name. And that is only done for java.util.function.* functional interfaces. It's this hard coding of java.util.function.* that made we wonder: is JDT in a good position to decide which strategy is better in which case? There are other libraries providing general purpose functional interfaces. Should they be included? Will users ask for a preference to list additional functional interfaces to use the alternative strategy? > > It seems that the lambda-proposal uses linked mode after insertion. Can you > > offer additional heuristics as alternatives in linked mode? Since there's no > > one strategy that fits all, presenting alternatives would feel natural to me. > > > > yes we could do that, but then the user needs to always select the parameter > from the list where we suggest the original and computed isn't it ? The first proposal from the list can be accepted without further interaction. Alternatively, a user may find a better proposal down in the list. If proposals are sorted in a useful way (e.g., using the very rules you have implemented), than in most cases users wouldn't have to do more, but in the remaining cases they could select an alternative with just one click or few keystrokes. IOW: if JDT has difficulties deciding which strategy is best, why not pass that decision down to users? I'm sorry I joined this discussion late, so feel free to ignore, if everybody is comfortable with the design.
(In reply to Stephan Herrmann from comment #13) > (In reply to Gayan Perera from comment #12) > > (In reply to Stephan Herrmann from comment #8) > > > @Gayan, is your change *replacing* the existing naming strategy? > > > > Yes we change the orignal naming strategy if we can find a better variable > > name. And that is only done for java.util.function.* functional interfaces. > > It's this hard coding of java.util.function.* that made we wonder: is JDT in > a good position to decide which strategy is better in which case? There are > other libraries providing general purpose functional interfaces. Should they > be included? Will users ask for a preference to list additional functional > interfaces to use the alternative strategy? Yes this is something problematic with the current approach. I agree. Because if JDT start deciding things for users, then JDT needs to be more opinionated, from my experience thats not the Eclipse way of working which i love about Eclipse. So may be we in JDT Core should only resolve conflicts like decimals.stream().filter(t -> { Stream.of(args).filter(t -> ).findFirst().isPresent(); }) So the second predicate can suggest t2 instead of t from JDT. > > > > It seems that the lambda-proposal uses linked mode after insertion. Can you > > > offer additional heuristics as alternatives in linked mode? Since there's no > > > one strategy that fits all, presenting alternatives would feel natural to me. > > > > > > > yes we could do that, but then the user needs to always select the parameter > > from the list where we suggest the original and computed isn't it ? > > The first proposal from the list can be accepted without further > interaction. Alternatively, a user may find a better proposal down in the > list. If proposals are sorted in a useful way (e.g., using the very rules > you have implemented), than in most cases users wouldn't have to do more, > but in the remaining cases they could select an alternative with just one > click or few keystrokes. > > IOW: if JDT has difficulties deciding which strategy is best, why not pass > that decision down to users? Yes i now also feel its better to suggest better names that *JDT Thinks* and let user decide. may be if the original name is a single letter, the JDT suggestions could be moved top. > I'm sorry I joined this discussion late, so feel free to ignore, if > everybody is comfortable with the design. I think you bring good insight Stephan, i really value that. Specially in a project like this which we need to look at the wholistic picture. You always surprise me with things i missed and i always learn from them.
@Jay if you also think we should only resolve conflicts in JDT Core and then move the better variable suggestion as a choice that user needs to make, Let me know so i can start changing the patch accordingly
(In reply to Gayan Perera from comment #15) > @Jay if you also think we should only resolve conflicts in JDT Core and then > move the better variable suggestion as a choice that user needs to make, Let > me know so i can start changing the patch accordingly Yes, that would be the safest option, IMO.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
