This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | [retouche]Implement all abstract methods generates methods that already exist if imports not resolved | ||
---|---|---|---|
Product: | java | Reporter: | _ tboudreau <tboudreau> |
Component: | Source | Assignee: | Jan Lahoda <jlahoda> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | ||
Priority: | P4 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
_ tboudreau
2006-11-01 14:29:33 UTC
Sorry, but I think this is currently as designed. Reopening - sorry. The IDE should never generate uncompilable code - it makes users not trust it. Surely we can detect if we are generating a method with an identical signature to one which already exists - just do a string compare of the name of the unresolved class with the code that would be generated, and if identical, don't generate the method stub. Really - any case where we generate code that is obviously uncompilable is going to make users not trust NetBeans and say bad things about it. In this case, we can do something about it - so we should. Sorry, but I do not think that string matching would be really error prone. What I can do is to disable the Implement All Abstract Methods hint if there are any unresolved identifiers in the given class, which should prevent this situation. The first sentence of my previous comment should obviously read "Sorry, but I think that string matching would be really error prone." :-). Not sure disabling the hint is correct in this case. -- And definitely disagree refactoring/suggestion should never create uncompilable code. Sometimes it is reasonable and even desirable to create uncompilable code. I remember such a discussion when I implemented 'Change method parameters' refactoring. When updating method call with value, I intentionally used unique non-existing value, then I compile and use errors to update all the calls with correct value. Or, when removing parameter, I prefered just warn user about used parameter when he tried to remove it. Then, he could simply remove all parameter usages in source where errors occured. Just my opinion. Given public Foo doSomething() { } and a hint that wants to generate "public Foo doSomething()", what is so error prone about comparing "Foo" with "Foo"? Even if the return type is Foo.Bar and the existing method has an unresolved "Bar", it should be relatively simple to handle. Or couldn't invoking the hint first add the import for Foo, then recompute the list of methods that need to be added, in which case "public Foo doSomething()" will not be in the list? In that case, it would do this correctly. > Sometimes it is reasonable and even desirable to create uncompilable code.
Agree that there are such times; disagree that this is one of them.
I agree with Pavel that the idea with disabling the hint is not a good one. Regarding the imports, the hint actually does not know how the type will be imported, or even if the type will be imported at all (the settings may order use of FQNs). This is done in the import management code to ensure consistency. Imagine (public) classes a.B.C.D and a.E.D (B and E are top-level classes). Imagine an interface X1 with a method like x(a.B.C.D d), an interface X2 with a method like x(a.E.D d) and a class like: package a; class Y implements X1, X2 { x(D d) {} } What should the hint do? In a super rare case like that? Ask the user. later. NetBeans.org Migration: changing resolution from LATER to WONTFIX |