"Generate Collection Methods": two small questions
1) The "Collections" class method calls are inserted with "Collections" as
a FQN:
-
public Set getUnits() {
return java.util.Collections.unmodifiableSet(units);
}
-
2) Members of type java.util.Collection are not available for selection
3) It would be nice if a rename of the member would recognize the generated
methods, and include these.
Please sign in to leave a comment.
Wow! Someone using "Generate Collection Methods"! In honor of actually hearing from someone an actual user, I'll fix issues 1) and 2) (both long known, but I've just never bothered) and put out a release. 3) would be very cool, but may be difficult, so no gaurantees.
--Dave Griffith
Well in this case, could you make it so the methods are inserted at the
cursor instead of at the end? :)
Dave Griffith wrote:
Sure, sure, although if the requests get any more involved than that I'll probably sell the whole plugin to Sixth and Red River, for inclusion in Refactor-J 2.0.
--Dave Griffith
Is there any functionality in the OpenAPI that allows one to listen to refactoring
events (e.g. rename), and contribute additional modifications?
One idea (not really a suggestion) is to include safe (cloning) getters/setters
for mutable types (java.util.Date and others).
Motivations are the same as those for the 'Collection Methods'.
Taras Tielkes wrote:
>> 3) would be very cool, but may be difficult, so no
>> gaurantees.
RefactoringListenerManager allows listening for rename and move
refactorings.
1.0.2 is up on the plugin site now, and covers all of these requests other than the automatic renaming. Methods are added at the cursor, rather than at the end of the class, if possible. Automatic renaming will probably be added within the next couple of weeks.
--Dave Griffith
Oooooh, I like that, and it would take about an hour to implement from the current base. Date, Calendars, what else?
--Dave Griffith
Hello Dave,
I would suggest Throwable.
Apart from that, a cloning array setter would be nice as well.