generic programming の文脈では C++ のクラスは限定的に open だよ？

C++ において class は open か closed か．自分は「generic programming の文脈では限定的ながら open であるといってしかるべき」と思うのだけれど．思っただけ．
C++ の class には associated namespace というものがあって，そこには class の public なインタフェイスに依存する形の新しい関数 (behavior) が追加できる．そして，関数テンプレート内における unqualified call の形の関数呼び出しは，この associated namespace に追加された関数定義を発見できる．この意味で C++ の class は open だと主張する．
何言っているのかサッパリ妖精なので，やや具体的な文脈で書いてみる．
Aさんは LibA::Hoge という型を定義した．Aさんは後で登場する LibB::hige という関数テンプレートで，自分が定義したこの LibA::Hoge という型を使用することは想像していなかった．

namespace LibA{
class Hoge
{
  ...
};
}

さて，Bさんは LibB::hige という関数テンプレートを作った． LibB::hige の実装は hage というインタフェイス (非メンバ関数であることに注意) に依存する．Bさんは，Aさんが作った LibA::Hoge という型の存在を知らず， LibA::Hoge には hage というインタフェイスが無いことは知ったこっちゃなかった．あるいは，知っていたけれど LibA::Hoge に対して特殊化することを選択しなかった．

namespace LibB{
template<class T>
void hige(T const &x)
{
  ...
  hage(x); // namespace の指定が無い形の呼び出しであることに注意
  ...
}
}

ここでAさんとBさんが別の人物であることは特に仮定していない．AさんとBさんが同一人物であってもこのような状況はしばしば発生するし，またAさんとBさんが同じ人物で，なおかつ，このような状況を意図的に発生させることには十分な論拠がある場合も多いと考える． (多くのコンポーネントとの協調を想定すると，ひとつのクラスに大量のインタフェイスが付随してクラスが肥大化する嫌いがあるため，実際にコンポーネント間の相互運用が発生するまで gluing の実装を遅延することにはそれなりの正当性があると思われる)
今，ここにCさんが居て，Aさんが作った LibA::Hoge を，Bさんが作った LibB::hige で使いたいと考えた．ところが LibA::Hoge には残念ながら LibB::hige で必要な hage が無い．しかしながら， Lib::Hoge の public なインタフェイスを用いて LibB::hige が必要とする hage の実装が実現できるように思われた．Cさんは LibA::Hoge の定義を変えることなく， LibA 名前空間に LibA::Hoge のための hage インタフェイスを追加し， LibA::Hoge が LibB::hige で利用できるようになった．

namespace LibA{
void hage(Hoge const &x)
{
  ...
}
}

Hoge h;
LibB::hige(h); // O.K.

ここでもまた，CさんはAさんと同一人物かも知れないし，はたまたBさんと同一人物かも知れない．
LibA::Hoge の定義を変えることなく (LibA::Hoge の定義に侵入することなく; "non-intrusively") LibB::hige への extensibility/adaptability を獲得できる，これが C++ における generic programming の基軸の1つだと自分は考える． (そして，このことから C++ における generic programming では非メンバ関数に依存する形態が推奨されることが多い) この，クラス定義に触れることなく， associated namespace に関数を追加することによって，汎用コンポーネントへの extensibility/adaptability を獲得できるという意味で C++ の class は open である，と表現してしかるべきだと思う．
以下余談．
そうすると， generic programming @ C++ の現行規格における各種の問題 (e.g. 演算子は誰のものか) は，結局，他の open な class 定義を持つ言語が抱える問題 (誰が class に定義を追加するのか/できるのか，一度何かを追加してしまうとそれが全員に見えてしまう) と根は同じではないかと思えてきた．
open な class を持つ言語がどうやって抱えている問題を解決しようとしているかを見てみれば， C++ における generic programming の問題の解決の糸口も見えてくるかも知れませんねー，っていう．まー， scoped concept maps ﾏﾀﾞｧ-? （･∀･）っ/凵⌒☆ﾁﾝﾁﾝなんだけれど．