| T O P I C R E V I E W |
| KirillMueller |
Posted - Aug 19 2006 : 08:01:49 AM
In version 1532, "Add Implementation" adds the implementation to the end of a module that has the same name as the header file. That's well-defined. However, my project has a huge Main.h file where all classes are declared, and it also features a Main.cpp file that contains code not related to the classes. Now the "Add Implementation" creates the implementation where I would least expect it.
Why wouldn't VAX insert the code just below the method whose declaration is above the method to add the implementation for? For instance, with the following class
// AnyHeader.h
class A {
public:
A();
~A();
private:
void someMethod();
int newMethodToImplement();
void someOtherMethod();
};
"Add Implementation" would insert the implementation of newMethodToImplement would go just there ->>
// AnotherModule.cpp
A::A() {
...
}
A::~A() {
...
}
void A::someMethod() {
...
}
// ->>
void A::newMethodToImplement() {
...
}
// ->>
void A::someOtherMethod() {
...
}
If someMethod() wasn't implemented or was implemented in-line (in the header file), VAX could try the closest declaration that has an implementation in a module, in that case, someOtherMethod() or ~A().
Are there specific advantages in having most recently added methods at the end of file? If so, VAX could offer a configuration option.
To the very least, VAX could try to add the method at the end of that file that contains most implementations of methods of this class. Or offer a menu, just like after Alt+G.
Any opinions? |
| 4 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Aug 20 2006 : 12:48:22 PM
i have put in a feature request for this. the basic idea is to give you control over where the new implementation is placed in the code.
case=2161 |
| accord |
Posted - Aug 19 2006 : 10:09:10 PM
I thinked about this idea also.
Feline: if you think it is a good idea, can you create a case for it? 
I think it is acceptable if this new feature firstly will working correctly only on non-overloaded functions and non-operators. 
Yes, if you press Alt+G, sometimes VAX asking a question. The create implementation should accept the first version of function. If Alt+G gets smarter, this feature can be also... 
What do you think about it? |
| KirillMueller |
Posted - Aug 19 2006 : 10:04:51 AM
Feline, thank you very much for your quick reply.
Yes, basically, I try to keep header and implementation in the same order. (Sorting implementations by declaration order would be a nice option for refactoring, too ).
The concept of "the header" and "the implementation" sure is simple and may hold for many cases, but not for all. VAX knows quite well which CPP module contains which implementations: Alt+G works fine for me. My suggestion is to drop the "header=implementation" concept and use the mechanism already implemented for "Find implementation" to locate the file (and the position) where new implementations go.
Nobody expects the rather lightweight but fast parser in VAX to be perfect. If VAX can find the implementation in a majority of cases, this saves time already. Consequently, if VAX inserts the implementation at the right position in, say, 80% of the cases, this is perfect. The user will notice when VAX choses a wrong position, and do whatever is necessary to correct it.
Ok, forget about options. So, if changing the current behavior in any way, we need to find a common denominator which would suit most users.
I wouldn't mind VAX asking a quick question if it is unsure about the user's intention, just like with Alt+G. Answering a question, if it's necessary, is cheaper in terms of keystroke count than correcting VAX's possibly incorrectly guessed action. And saving keystrokes is a basic purpose of VAX, right? That said, imho, having VAX guessing the correct position of the implementation (and optionally offering a choice if it's unsure) could be more effective from the programmer's point of view than just adding the implementation to the end of a file.
The idea in topic 5123 (Create implementation to clipboard) sounds good, one could fall back to that if VAX constantly does the wrong thing. Why not doing both -- insert an implementation AND leave it in the clipboard? The user could then undo the insertion by Ctrl+Bksp and instanly paste it to a different location. As VAX comes with a multi-clipboard, users won't get annoyed by destroyed clipboard text. -- Currently, I add implementations by typing them -- VAX helps saving keystrokes by offering correct suggestions for most cases. Clipboard would be faster, I guess.
For different reasons, I would prefer to stay with the current setup of my code. If VAX does not offer one or another functionality for my case, I can cope with it -- it's still far better than the built-in IntelliSense . |
| feline |
Posted - Aug 19 2006 : 09:17:02 AM
there is a request to keep the header file and the cpp file in the same order when using create implementation. i believe you are looking for the same basic behaviour.
due to a combination of operator overloading and default parameters VA cannot reliably determine which declaration in the header file goes with which function implementation in the cpp file. VA gets this right in "simple" cases, but not all code is simple.
this difficulty also effects other refactoring operations, plus alt-g. there are vague plans to tackle this problem, but until that is done i am not sure how VA could easily get around this problem. we don't want to ask the user any more questions than absolutely necessary. the design decision is to keep the refactoring operations very simple, very small, and with the minimum number of options and questions. this then lets people chain them together in what ever manor best suits them.
you may find the idea in this thread interesting http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=5123
on a slightly different front, you may find it useful to try and split your code up so it uses more files, with fewer functions in each one. i know this can sometimes be very difficult, but if it is possible it will probably make it easier to maintain and navigate the code. |
|
|
