| Summary: | Modifying declaration and definition in the same widget. | ||
|---|---|---|---|
| Product: | [Applications] kdevelop | Reporter: | Steven T. Hatton <hattons> |
| Component: | general | Assignee: | kdevelop-bugs-null |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | CC: | bluedzins |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Hey! That's not fair! The stupid thing sent itself before I finished. All I did was hit the space bar a few times.
Anyhow, to make a long story short.
the declaration of MyClass{...}; (technically that is a definition) would result in the instantiation of a runtime object in kdevelop representing the class.
// in header
MyClass{
void foo();
}
// in source
void MyClass::foo(){...}
would be treated as a single object and member of the object representing the class. The aspects that differ could be glued together as needed. For example, the qualifier doesn't appear in the declaration of a member function, only in the definition (implementation). It could be treated as a separate chunk of data from the type name, function name, parameter list, cv-qualifiers, etc. Certain items need to be bound together, for example, the name of the function must be identical in both the header and source, I see no problem in enforcing an exact correspondence between parameter names in the declaration and definition, so long as there is an override mechanism available for cases where people would rather modify the code idiosyncratically and not rely on the IDE to synchronize things for them.
As I hinted above, I'm sure all this is easier said than done. I just thought I'd try to get folks thinking along these lines.
|
Version: (using KDE Devel) OS: Linux An obviously desirable, thought potentially difficult feature to support would be the reediting of declarations and definitions sa a unit. That is, If I have a function declared in a header and corresponding implementation in a source file, there may be a way to treat the two elements of code as multiple representations of the same data object. The wizard would then be able to provide an interface (widget) through which the user could change the names or types of the parameters or even the name of the functions or attributes by modifying one text object. If that can be accomplished, it would probably not be much more of a feat to modify the member initialization list, and ordering of declarations in the class through this approach. What I'm saying is that it may be possible to represent a class, and members thereof, as a runtime instance of a C++ object. The user would then be able to work on the object as a unit, and work on declarations and definitions in a form representing the single abstract concept. //file MyClass.h (I prefer MyClass.hh, but I prefer uniformity more.) #ifndef NSPACE_MYCLASS_H #define NSPACE_MYCLASS_H #include "IHateTheCPP.h" #include "..." namespace nspace{ // perhaps even the namespace could be treated as an object. class MyClass{ } }