[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 66683] Implement Code refactoring
From:       Eric Laberge <demon_lord () myrealbox ! com>
Date:       2006-01-24 22:05:19
Message-ID: 20060124220519.24900.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=66683         




------- Additional Comments From demon_lord myrealbox com  2006-01-24 23:05 -------
Michael, after all your posts, I'm not as pessimistic as before for the use of an \
existing parser :-)

In fact, I'm overly optimistic that this tool could be coded good enough that the \
underlying parts (parser/database/structures/refactoring API) can be abstracted \
enough to not matter anyway. Maybe I overvalue the use of patterns and our ability to \
refactor our own code, but I think we should make an example of good and extensible \
coding styles.

I've thought again on the SQL backend, and must say I've "seen the light" as its \
flexibility to handle most, if not all refactorings. I'm however not sure it's the \
good tool for everything, but with some abstraction in its use, I don't think it \
matters anyway.

I'm not as verbose on this bug report discussion as Michael, but I do think it's time \
for this project to actually move on. I think our first goal should be to fill up the \
wiki with refactoring algorithms/possible (SQL?) implementations and project goals. \
This will help us determine the required data structures and work our way up to a \
functional product.

I won't post in this bug report anymore, unless it's directly related to KDevelop \
(ie.: KDevelop refactoring dialogs or whatever). http://carl.sourceforge.net


[prev in list] [next in list] [prev in thread] [next in thread]