要は現存する継承以上のコンパイラマジックが欲しいなあと
相変わらず元ソースを見ずに。
http://d.hatena.ne.jp/soutaro/20051002/1128246449
大方の言語でサブタイプが継承とinterfaceに限定されるのは…単に実装の都合じゃないかなーと。
class id {
int number;
string name;
};
class action {
void execute();
void update();
};
class menuitem {
string name;
bool checked;
void execute();
};
とかあって、
class command {
int number;
string name;
bool checked;
void execute();
void update();
};
が、オブジェクトベースのインタプリタ言語よろしくid, action, menuitem全てのサブタイプになれると、メモリイメージどうなるんだって話で…フィールドひとつひとつに対するアクセスがC++のvirtual継承みたいになるのは目に見えてませんか…。
単一継承ならVMTは各オブジェクトにひとつずつで済みます。多重継承やinterfaceでも、VMTは明示的に継承するぞと指定した数だけで済みます。interfaceは言ってみればメソッド限定の継承を伴わないサブタイプで実際効率あんま良くないですが、これがフィールド変数も同様に扱うとなると、VMTエントリにフィールドの位置も格納する必要があります。さらに明示的な継承無しで、後付で必要な要素を全て含んでいればなんでもサブタイプになれるとすると、メンバ変数の数だけVMTが…。
小さい.exe信奉者*1としましては、interfaceとクロージャあれば継承要らないというのも同様で、継承は諸々の概念と同時に、派生先の一部が親とメモリイメージが同じであることを保障して親をアクセスしているつもりのコードに派生先を渡せるコンパイラのトリックでもあるわけです。抽象データ型オブジェクト指向上の多態*2を効率最優先で実現するための先人の知恵といいましょうか。この仕組みを、使えない場所で使わないのは当然にしても、完全放棄してコードエリアを無意味な委譲コードで埋めてしまうのは、委譲コードを書くのが面倒くさいのと同じぐらいに耐えられないものに思えます。*3
まぁそれ以前に、私は継承をいけないものとは思ってないとかそもそもオブジェクト指向を徹底することにも疑問を持っているのは前に書いた通りですが、そこを譲って、継承を使わないのが望ましい、としても、同等のベタ書きと比して効率が落ちすぎるようであれば、それは目的と手段を取り違えていると感じてしまうと思います。
…で締めくくろうと思ったのですが、メモリイメージを静的に決めようとするからそうなるのであって、実行時のコード生成がありならばありの気がしてきた。
