Iterator/Descriptor/PropertyMap による抽象化は非常に完成度が高く， Boost.Graph に限らず，汎用プログラミングの1つの高度な到達点だと思っていて，これによってとりあえずプログラムが走るようにデータ構造をでっち上げておいてから，後でデータ構造をちょこちょこ変えるということが「ユーザ側のコードの変化を全く伴わずに」可能になるという強烈な利点があり（ただし，この恩恵を得るためにはユーザ側のコードがきちんと Iterator/Descriptor/PropertyMap の Concept のみに基づいて書かれていないといけない），さらに極端なケースとして，データ構造をメモリ上に全く展開することなく，全てを Iterator/Descriptor のインタフェース内部で on-the-fly でデータ構造を現出させているかのような仕様変更にすら「ユーザ側のコードの変化を全く伴わず」耐えることができる．もっともこの例はかなり極端だけれど，より現実的なユースケースとしてはメモリ上に部分的に展開された（巨大な）データ構造，例えばストリーム上に乗っているデータ構造やら，メモリより相対的に遅いストレージに一部が乗っているようなデータ構造に対しても，やっぱり「ユーザ側のコードの変化を全く伴わずに」対応できるキャパシティを潜在的に持っていると思われる．
で，そんな雲をつかむようなワケの分からない話はどちらかとゆ〜とどーでもよくて，上のように強力なデータ構造抽象化能力の一翼を担う PropertyMap についてちょっと個人的なメモ．
前に， PropertyMap のインタフェースは operator[] じゃなくて operator() で提供するべきじゃないのか？っていう話題があってこのブログでもチラッと取り上げたけれど，
http://d.hatena.ne.jp/Cryolite/20050429#p1
http://article.gmane.org/gmane.comp.lib.boost.devel/121406
本当にインタフェースを operator() にすると， PropertyMap って結局関数オブジェクト（一般には PolymorphicFunctionObject） の Refinement になるんちゃうの？ってゆ〜．で PropertyMap は mapping 先のオブジェクトに対する書き込みを許すものもあるので，一見すると関数（mapping）の純粋性を破るような気がするけれど， PropertyMap は mapping 先の値を返す関数と考えているのではなくて， mapping 先そのもの（つまり値が置かれているストレージへの参照それ自体，ただしそれが実際に参照型で表されていない場合も多々ある）が返却値だという捉え方でいけば，純粋な関数となる……のではないか？ってゆー．っていうか， PolymorphicFunctionObject の Refinement で，特にこういう捉え方を要求するものがつまり PropertyMap コンセプトという考え方はダメですかそーですか．
