■

自身が定義したユーザ定義型とか， third party から提供されるクラスとか， built-in な型とか，そういうのを汎用なライブラリで使用するにあたって，静的な世界の糊付けを行うのが (template metaprogramming +) traits で，動的な世界 (振る舞い, behavior) の糊付けを行うのが policy という観点で色々書こうとしたけれど，それだと third party の library だろうが built-in types だろうが adaptor を作れば引き込めるじゃん，という反論を考えたあたりでどんづまった．アダプタのインタフェース透過性とかアダプタを噛ました場合オブジェクトのライフタイム管理とか色々反論はあるけれどあーあーあー．
＃あ，決定的に違う．普通の継承 (named conformance) による polymorphism だと明示的・宣言的に何らかの関係 (クラス階層の兄弟である) つーのが要るんじゃ？ (C++ の) 汎用プログラミングだと汎用コンポーネントで使いたい型・クラスは少なくともフラット (ぺったんこ！) で良いからうれしい．こういう意味でも intrusive か．か？もちろん概念的な兄弟関係 (すなわち何らかのコンセプトのモデルである) っつーのは要るけれど，それはコード上では non-intrusive に後付けできるわけで，そういう意味でも強力か．か？
＃あれ？途中で論点がスライドしてる？だからアダプタ使うほうでも non-intrusive なわけで……？
最大の弱点は (TMP +) traits にしろ，(ADL hook で提供する) policy にしろ，糊付けのコンポーネントがあっちゃこっちゃに散逸することなんだろうけれど，その弱点攻撃されても「そもそも (library 間の interoperation を司る) 糊付けのコンポーネントを集約する構造が必ずしも正しいとは思えない」という反論はあるっていうか，「必ずしも正しいとは思えない」って反論は弱いような気がするぞぞぞ．
結局，非侵入性 non-intrusiveness と糊付けのコンポーネントの散逸 scattering というトレードオフの構造か！……構造か？ concept-based specialization / concept-based overloading が解決してくれないかなぁ．それで解決できたとしても，それは結局 type system for types つー一段メタな世界に構造と問題を押しやっただけのような？
このままオブジェクト指向プログラミングと (C++ での) 汎用プログラミングの慣習の違いに関する部分にまで突っ込んでいけるような気がするけれど，それ以外の軸，例えば value-based と entity-based の違いとかも絡んでくるような気がするようなしないような．