IDocumentとIProgressMonitor関連

Irenka

某カンファレンス中にちょろっと話した内容をまとめていただいたようで。

重要なのは、JDTのモデルを触る時には、以下の点について考慮しないといけない事です。

  • 現在エディタで開かれているかどうか
  • ファイルの実体を変更するかどうか。つまり、エディタ上でCtrl+Zで戻れる様にしたいかどうか。
  • IProgressMonitor も忘れずに。要は、進捗報告と、処理のキャンセル可能性を忘れない事。
ICompilationUnitを、変更するコードパターン - 設計と実装の狭間で。

ICompilationUnit周りのバッファ、テキストエディタのバッファ、IDocument周りについて何となく設計思想がつかめました。

ただ、IProgressMonitorはどうしようかなぁ…
IrenkaはできるだけEclipseに依存しないように書いているので、低層でライブラリ内の型とか使うときは緩衝材を使わないとだめそうです。でも、ASTParserとかを使うところではIProgressMonitorという型が重要になってくるので、依存せざるを得ないというのも理解。

そこで、IAdaptableっぽいものを用意しようかなと。

public interface CtAdaptable {
    <T> T getAdapter(Class<T> type);
}

public interface CtProgressMonitor extends CtAdaptable {
    // (IProgressMonitorのラッパーっぽく)
}

この状態でCtProgressMonitorを持ち歩いて、必要に応じてIProgressMonitorを利用するイメージ。

public class JavaDeclarationInfoPath implements CtDeclarationInfoPath {
  ...
  public CtCompilationUnitInfo findCompilationUnitInfo(String className, CtProgressMonitor monitor) {
    ...
    CompilationUnit unit = parse(dotJava, root.getJavaProject(), monitor.getAdapter(IProgressMonitor.class));
    ...
  }

  public static CompilationUnit parse(ICompilationUnit java, IJavaProject project, IProgressMonitor monitor) {
    ASTParser parser = ASTParser.newParser(AST.JLS3);
    ...
    CompilationUnit unit = (CompilationUnit) parser.createAST(monitor);
    return unit;
  }
}

ただ、結合が疎になりすぎてコードトレースが困難になるという懸念も。しかもEclipseプラットフォームAPIの s/\.I/.Ct/ なインターフェースがたくさんできそうな。