Automatic code refactoring

[Matt Rogers]

On Tuesday 01 March 2005 04:11 pm, Calvin Spealman wrote:
> Richard Dale wrote:
> > Excellent! But what about using Bicycle Repair Man, and just adding a UI
> > to it? That's what Eric3 does, as otherwise you'd have to re-write it.
>
> I probably will start with a UI for BRM, but I would like to continue by
> expanding on BRM or adding features to KDevelop itself in such areas.
>
> > At the moment the ruby class parser uses just regular expressions, and it
> > isn't much more complicated than the python one. I'd like to improve it
> > for KDevelop 3.3 by using the actual ruby 1.8.2 bison grammar and
> > tokeniser. But I don't see any need for a common parser as long as the
> > things we do with the parsed data is language independent, which it is at
> > present.
>
> The benefit is that all these languages already have BNF/EBNF files readily
> available and so a centralized parser will reduce develop time of new
> language support, as well as reduce the likely-hood of incorrectly parsing
> these new languages.
>
> In many cases, the BNFs could also be used to derive some scope information
> from the source, leading to better autocompletion, among other things.

so all the languages kdevelop supports has these BNF/EBNF files available 
already? While a centralized parser sounds like a nice idea, I don't see how 
the project would gain much from it other than perhaps normalizing the 
features available between all the language parts and reducing somewhat the 
amount of code.

the big problem with things like code refactoring and autocompletion, etc is 
not so much the parser, but the code model that the language part relies on 
to get the information to carry out those actions, so perhaps more effort 
should go into a better code model

my 2 cents,
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20050307/6a089551/attachment.sig>