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