うーん、どういうデータ構造が欲しいんでしょうねぇ? PRIMARY KEY の一覧くらいか?
定石は全部読んでみること、つまり get_next_key() を呼びまくるコードです。 専用のメソッドがあった方が便利でしょうけど、 滅多にそんなコードは必要ないようなので、 専用メソッドがなくても問題はないようです。
もし、あるとしたら get_primary_keys() みたいな名前のメソッド?で、 ARRAY_REF で返すのでしょうかね?でも、find('*', { all => 1 }) などとす ると全部の KEY の値がARRAY_REF で返りますんで、別のメソッドも不要な気 がするねぇ。
(KEY1 KEY2)
これこそ、どういうデータ構造が欲しいんでしょうねぇ? 返り値が HASH_REF であるようなメソッドが欲しいのだろうか?
返り値 = { 変数1 => 値1、 変数2 => 値2、 }って、つまり getattr(KEY) とかいうメソッドかなぁ。だが、HASH_REF 中の 属性のキーがオブジェクトに強く依存するわけですが…そんなので modular といえるのか?
単に、表のN番めじゃなくて、N番目の名前はこれこれ…っていう情報のタグ をつけて返すと思えば、あまり変わらないといえば変わらない。
メールアドレスに属性をつけることを考えるとこういったものが必要でしょう。 たとえば、まとめ送りがその例といえる。
メールアドレス => { 送り間隔 => 3時間、 ファイル圧縮 => しない フォーマット => mime/multipart };
ただ、キャッシュを抽象化したアダプタ層はこの形になりうるでしょう。 たとえば
FML::Error -> FML::Error::Cache -> Tie::JournaledDirこういったキャッシュのアダプター層のために、標準規格があるとよいです。 全部 Tie でやるってのもあるけど、Tie で書きまくると、どんどん HASH の 中身が複雑になって、一番下の Tie:: の替えがきかなかったりしそうで、な んかいやなかんじではあります。
author's homepage is www.fml.org/home/fukachan/.
Also, visit nuinui's world :) at www.nuinui.net.
For questions about FML, e-mail <fml-bugs@fml.org>.