Bug 454905 - Guess superclass / interface when creating a new class
Summary: Guess superclass / interface when creating a new class
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.3.2   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-11 10:58 EST by Andy Lowry CLA
Modified: 2014-12-11 10:58 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Lowry CLA 2014-12-11 10:58:15 EST
I'm frequently in the position of creating an interface or abstract class named Foo, and then several classes that implement/extend FooBar with names like XxxFooBar. I've seen this pattern used elsewhere as well.

It struck me that the Eclipse Java UI could detect this sort of situation fairly easily in the New Class dialog. When I type MumbleFooBar for my new class name, Eclipse could notice that FooBar names a known interface or abstract class and then fill that in automatically as the new class's superclass or one of its interfaces.

When this happened correctly it would be a nice assist. But when Eclipse got it wrong it would be annoying. So probably one would want to be able to configure the scope to be used for guessing. Scope options could include file, package, project, and workspace, and only types that are in scope relative to the new class would be considered. And of course one should be able to turn this off completely.

I'd probably only want interfaces and abstract classes to be used for this, but obviously, non-final concrete classes could also be guessed as a superclass. I'm thinking that would be an additional config option, defaulting to interfaces and abstract classes only.

It could happen that there are multiple candidates for a given class. E.g. perhaps MumbleFooBar could be based on either Bar or FooBar, or there could be multiple FooBar types in scope. In this case, perhaps it'd be best to avoid guessing. Alternatively, heuristics could be used to pick - e.g. the "closest" candidate in terms of project/package/file structure, and/or the candidate with the longest name (FooBar beats Bar)?