読者です 読者をやめる 読者になる 読者になる

キーワードを左に

.NET

(似たような質問をもうひとつしようとして途中で混乱してしまい,大事な時間を浪費してしまって後で激しく後悔したというのは余談というか詳しくは今度書きます)

について.
意図していた話は概ねこんな感じです.
Visual C# の IntelliSense の機能で,メソッドオーバーライドの候補表示と戻り値の型による絞り込みがあります.例として次のような基底クラスがあるとします.

public class Base
{
    public virtual int Foo()
    {
        return 0;
    }
    public virtual void Foo(int i)
    {
    }
    public virtual string Foo(string s, int i)
    {
        return s + i;
    }
    public virtual string Foo(string s, string t, int i)
    {
        return s + t + i;
    }
}

このとき,新たに派生クラス Deriv で Base クラスのメソッドをオーバーライドするとしましょう.まず単純に override キーワードを入力したときに表示される候補がこれです.

オーバーライド可能なメソッドとして 7 つの候補が表示されているのが分かります.
さらに戻り値の型として string を入力するとこうなります.

一方で最初の候補ウィンドウ表示時には string 以外にも "Foo" と入力することで直接メソッドの候補選択も可能になっています.

一見当たり前に見えるこの動作ですが,override キーワードの直後にメソッド名が来ているこの書きかけの状態は「メソッド名の前に戻り値の型を書く」という C# の文法から見れば「変な状態」です*1 *2
で,あのとき聞きたかったことはどんなことだったかというと,「このように IDE による開発を(事実上)前提ととした言語では,単純なシンタックスシュガー以外にも IDE レベルでのギミックが可能となっていますが,IDE を前提に作られた言語仕様の部分は何かありますか?」というようなことだった気がします (混乱のためかなり記憶があやふや)*3
しかしまあ書いていて思いますが,すぱっと書けないあたり依然として私の中でよく整理されていない証拠でしょう.
IDE による入力支援に関しては,定性的には次のような傾向が言えそうです.

  1. 多くの場合ソースコードの入力は左から右に行われ,IDE による入力支援を早めに開始するには,より左側のキーワードがトリガーとなる/で判断可能であった方が良い.
  2. IntelliSense による入力の中間状態では選択後に自明となる項目を入力する必要はない (後で自動入力が出来る)
  3. using にしても CodeSnippet にしても,度が過ぎると一階層に選択候補が溢れることとなる.Visual Basic の My のように,緩やかな階層化の流れはあって悪くはないかもしれない.

このあたりの指標を元に,C#Visual Basic でどちらが「入力が効率的か?」を定量評価できるかもしれません.こういう「ソースコード入力の効率性」が学問になっているかどうかは分かりませんが,もしやるとしたら言語屋さんかつ User Interface 屋さんという中々微妙な線を突いておく必要がある気がします.意外と市場規模的には大きいと思うんですが,どうなんでしょうかね?

*1:C# 2.0 でも部分的には delegate (int x){ return i % 2 == 0; }と書けますけど

*2:よくよく考えてみると,C# が戻り値の型についてのオーバーロードをサポートしていないからこれで OK なわけですね.例外的にオペレータのオーバーロードは戻り値の型に関するオーバーロードで実装されますが,まあ override には絡まないですし.

*3:まあ partial types なんかがまさにそれなんでしょうけど