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.

Bug 233976 - refactoring method parameters: support for changing parameter type
Summary: refactoring method parameters: support for changing parameter type
Status: NEW
Alias: None
Product: cnd
Classification: Unclassified
Component: Code Model (show other bugs)
Version: 7.4
Hardware: PC Linux
: P2 normal (vote)
Assignee: issues@cnd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-05 23:55 UTC by tbrunhoff
Modified: 2013-08-07 17:19 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tbrunhoff 2013-08-05 23:55:22 UTC
I have a class that looks like this:
    class ClipData {
    public:
        virtual OpResult accessFrameData(uint_64, uint) = 0;
        ...
    }

And I want to change the second argument from a uint to a reference; i.e. uint&. There are six classes that override this method, and all declarations and usages need to be updated.  There are several problems; esp, #5 and #7 below.

Right click on the method -->refactor-->change function parameters.

problem #1: very minor. In the first dialog where List of Errors is "There are virtual methods...", there are two buttons that appear to have the same meaning: Preview and Next. There should be one button or it should be clear that they have the same meaning.

click Next or Preview, and you get...

+---------------------------------------+
|   Name     | Type     | Default Value |
+---------------------------------------+
| fileOffset | uint_64  |               |
+---------------------------------------+
| frameSize  | uint     |               |
+---------------------------------------+

problem #2: inconvenient.  I cannot change the name, type or default value of the existing  parameter. What a pain.  I have to delete the parameter and redeclare it.

Select frameSize, remove it and re-enter it as
+---------------------------------------+
| frameSize  | uint&    | 0             |
+---------------------------------------+

problem #3: bad constraint. The dialog insists that I provide a default value, but a default value will change the signature or the usage depending on whether "Use New Parameter Default Value Only n Declaration".  There should be two choices but not these two. They should be (1) no default value, (2) default value declared in declaration. The default value *not* used in declaration is possible, but that's another problem.

So... with "Use New Parameter Default Value Only n Declaration" *unselected*, click preview.

problem #4: bad constraint. The base class declaration and all derived class declarations are changed to
    virtual OpResult accessFrameData(uint_64, uint& frameSize) = 0;
Note that the parameter name has been added. In C/C++ this is not always desirable, but I believe it is a requirement in Java. The reason is that adding the variable name is only cosmetic, especially when the type is something richer datatypes where the type implies the usage (this usage is ambiguous as a uint).

problem #5: Critical! Usages in the code are all changed from
    OpResult result = accessFrameData(fileOffset, frameSize);
to
    OpResult result = accessFrameData(fileOffset, 0);
I cannot imagine a scenario where this makes sense.

problem #6: Highly inconvenient. There is no way to go back to the previous dialog to change the refactoring. Instead you have to start from scratch.

So start again and get to the refactoring dialog, and this time, with "Use New Parameter Default Value Only n Declaration" *unselected*, click preview.

problem #7: Usage change. All method declaration are changed to:
    virtual OpResult accessFrameData(uint_64, uint& frameSize = 0) = 0;
The problem here is *not* that you can add an optional argument, its that you cannot *not* add a default argument.
Comment 1 tbrunhoff 2013-08-05 23:55:36 UTC
Product Version: NetBeans IDE Dev (Build 201307212300)
Java: 1.7.0_25; Java HotSpot(TM) Client VM 23.25-b01
Runtime: Java(TM) SE Runtime Environment 1.7.0_25-b15
System: Linux version 3.6.11-4.fc16.x86_64 running on i386; UTF-8; en_US (nb)
User directory: /home/toddb/.netbeans/dev
Cache directory: /home/toddb/.cache/netbeans/dev
Comment 2 Vladimir Voskresensky 2013-08-06 08:44:26 UTC
Todd,

Thanks for the detailed scenario. Your tricks to get what you want with what we have supported so far cause more issues for user than help :-)

Let me change this bug to enhancement.
Comment 3 tbrunhoff 2013-08-07 17:19:28 UTC
> Your tricks to get what you want with what we
> have supported so far cause more issues for user than help :-)

Yes, any code change is has a high likelyhood of causing new bugs even if it successfully fixes the targeted bug. Such is life in the fast lane.

I honestly think that NB can and does beat Xcode, VS 2012, eclipse. But NB has lots of rough edges in c++. I suspect NB would stall on c++ if not for you, gorrus, simon and a few others. You certainly have my thanks.

You know, if I thought I could get over the learning curve to debug NB/c++ in a few hours, I'd probably submit patches. But it is a very big, complex codebase.