今日の入力補完。

eclipse

こんなDTOとDAOを用意。

public class Aaaa {
  private String hoge ="　";
  public String fuga ="";
  public String getHoge(){
    return hoge; 
  }
  public String getPiro(){
    return hoge;
  }
}
public interface HogeDao {

  String fuga(String str, Aaaa aaa, Map<String, String> m);
}

で、大体こんな感じ。IFコメントの最初で入力補完を起動。

aaaを選択して、.を入力すると続けて、入力補完が起動しるます。

publicなメンバがゴロゴロと出てくるます。


んで、同じ様に.を入力すると、こんな感じ


次は、バインドコメント。最初は同じ。メソッドのパラメータが候補になるます。


ここでは、OGNL書けないので、プロパティ名が候補となるます。
ここが、IFコメント内で入力補完を起動した時との違いです。


ここも、プロパティアクセスを複数回重ねる事もできるます。
ここは、Stringに対して、候補を出しているので、少し不思議な感じです。
java.lang.String#length()メソッドだけは、特別扱いしているます。


自分では、なるべく情報を抱えずに、
JDTの抱えているメタモデルを逐次的に検索しているので、そろそろ限界が来ているます。
具体的には、バインドコメントで、中途半端に入力して続きを入力補完する事が出来ませぬ。
部分しか無いと、フィールドの一部になるのか、メソッドをプロパティ風に丸めたものの一部なのか、
ﾜｶﾗﾝのでちと困ってしまいます。


Kijimunaの様にIJavaElementを丸めてキャッシュを作った上で入力補完してもいいのだけど、
それだと、パフォーマンス的に圧倒的な不利があるのです。
入力保管用の処理及びそれに関連するキャッシュの恩恵を受ける為には、

  • org.eclipse.jdt.ui.text.java.CompletionProposalCollector

のサブクラスを作って、ITypeやICompilationUnitに食わせないといけないのです。
今回の実装では、AmaterasのEclipse HTML Editor Pluginの実装を参考に、
メモリ上にのみ存在するICompilationUnitを作っているます。
これなら、入力補完時のoffset位置と置き換えの開始位置さえ弄れば、
普通に入力補完が効きます。