D Compiler as a Library
Marco Leise
Marco.Leise at gmx.de
Wed Apr 18 05:49:59 PDT 2012
Am Sat, 14 Apr 2012 22:44:07 -0400
schrieb "Nick Sabalausky" <SeeWebsiteToContactMe at semitwist.com>:
> "Jacob Carlborg" <doob at me.com> wrote in message
> news:jm9ulg$ui3$1 at digitalmars.com...
> >
> > * Refactoring
> >
>
> * Make DustMite even more awesomer by attempting to factor out functions,
> etc.
Something internal:
* Keep a view of every opened file in memory.
* Allow to manipulate that file with an interface like insert, delete,
replace of character ranges.
* Reparse only what has changed through that interface (remember datetime.d?)
This is to avoid CPU hogging and typing delays.
* Manage multiple open projects. That means sharing of the internal
representation of druntime/Phobos and libraries.
* We probably want two parser interfaces. Thinking of XML: SAX and DOM.
One parser iterates over the tokens and calls event handlers (no AST).
Example: lazy (line-by-line) editor syntax highlighting.
The other parser builds the whole module as an AST to work on.
Example: editing code multiple times in an IDE/refactorings
* If necessary, some sort of transaction, so a refactoring that fails in
the middle of the operation doesn't leave the code in a broken state.
* DDoc awareness. Cross-linked symbols etc. must be included when that
symbol is renamed.
I want refactoring to be as simple as Foo.renameSymbol("std.path.sep", "std.path.dirSeperator"); if the connection between module- and filename allows "std.path" to be traced back to the original file.
--
Marco
More information about the Digitalmars-d
mailing list