Community
Participate
Working Groups
I find the behavior of "Generate Constructor using Fields" is strange in some case. Suppose you have the following file: class ID { private int publicPart; private int localPart; } Then when you call "Generate Constructor using Fields", it generates: public ID(int part, int part2) { super(); // TODO Auto-generated constructor stub publicPart = part; localPart = part2; } I don't known why the names of the two arguments are "part" and "part2", instead of "publicPart" and "localPart". The first line of the generated code, "super()", is also unnessary. So I think it will be better if you delete this line if the class does not inherit from other class (except Object).
Move to JDT/UI
Tobias, can you please investigate why we take part and part2 here as names. We should do better here. Not for 3.1.
We take the naming conventions from JDT Core, but only the first proposal. We might consider also the other ones
I have followed the execution of this command and found the suggested name is given by function computeNames() in class InternalNamingConventions. For sourceName 'publicPart', this function will return 'part'. It seems that computeNames() thinks that 'public' is just a prefix and throws it away. If I make computeNames() return the sourceName first. I will get: public ID(int globalPart, int localPart) { super(); // TODO Auto-generated constructor stub this.publicPart = globalPart; this.localPart = localPart; } I think it's better than 'part' and 'part2'. But I'm not familiar with the internal of eclipse, so I'm not sure whether my fix is right.
This command has a second strange behaviour since it reorganizes the fields alphabetically. private String name; private String value; private int customerId; private int addressId; private int userId; becomes: /** * @param id * @param id2 * @param name * @param id3 * @param value */ public Customer(int id, int id2, String name, int id3, String value) { addressId = id; customerId = id2; this.name = name; userId = id3; this.value = value; } This is quite awfull ;) In 3.0.2 this worked like this: /** * @param name * @param value * @param customerId * @param addressId * @param userId */ public Customer(String name, String value, int customerId, int addressId, int userId) { this.name = name; this.value = value; this.customerId = customerId; this.addressId = addressId; this.userId = userId; }
Tobias: please adopt the convention of taking the longest proposal from JDT/core. See StubUtility.getArgumentNameSuggestions(..) and .suggestArgumentName(..). I agree that parameters must be created in the order of the field declarations.
Tobias, this is a regression to 3.0.1. Please investigate a fix for 3.1.1
This is very annoying, creating DTO objects has just become more complex... what I need is 1) exactly the same order as the declared fields 2) exactly the same name, that is this.myFieldWithAVeryLongName = myFieldWithAVeryLongName At least, as an option...
Regarding comment 1: The call to super can be configured in the Generate Constructors dialog
Created attachment 25847 [details] path for naming convention and order of the parameters Markus, Martin, can you please cast your vote for 3.1.1?
This would be good one to fix; it is really annoying as you have to refactor the contructor parameter names, and if you get that wrong you end up with silly bugs in your code. Voted for it.
The patch should use NamingConventions.removePrefixAndSuffixForFieldName on the field name before passing it to StubUtility.getArgumentNameSuggestions.
Created attachment 25887 [details] improved patch
Improved patch is ok. +1 for 3.1.1
Markus, can you please vote on this one?
Sorry to intrude, but asking is far easier than trying out the patch: does the patch solve both of the points I have issued? Same name, same order?
Yes, it fixes both issues
Created attachment 25988 [details] easier patch: reverted inline method Tobias, the improved patch makes a lot of changes in StubUtility2 that are IMO unnecessary. I refactored your patch to look more similar to the original code, and the only change left was replacing NamingConventions by StubUtility in getParameterName(..). I'd vote for my minimal-change patch.
+1 for the minimal patch
Fixed in 3.1.1 maintenance stream > 20050811
Fixed in HEAD > 20050815
verifying...
verified that everything works: - correct ordering - respect pre-/postfixes - chooses the same name as the field if possible after pre/postfix processing
