ねる :

なんか非常に同感です。なんか最近schemeを勉強して思っていたことがすっきりしたきがします。 ところで、ここでFPといっているのは closure のことのように思えるのですが、どうなのでしょう。 他のFPの要素 (って何だろう.... 副作用なしなスタイル? lazyness? よくわかってないです) が部品の再利用性の向上に著しく貢献したりするのでしょうか。 いや、Smalltalkでも十分同様なことができるのではないかなと、ふと思ったものですから。むしろ、Smalltalkのほうが closure つくるのが(タイピング数からみて)楽ですから良いのではないかと。

戯 :

• 前にも言ったけど、インタフェースの有無を問うのはOOPのうちの「一派」に過ぎないのでは？それこそOOPの定義は曖昧なんだから、その一派だけについての欠点を以って話を展開しちゃうと、ちょっと… --ドコに居てもWiLiKi:戯は戯
  • ちなみにそれって、それこそクラス指向ですね。
• ただ、手続きの無名化とか、手続きが「幾つ」有るか事前に判らない(ことを受け入れる)ことは、重要だと俺も思います。Ruby的Iteratorが無いのが嫌でJava使わなかったりするもんな。
  • で、もしかしてそういうの(卑近にいえばRubyのIterator)も「関数指向」に含めて捉えるべきだということなんでしょうか？まあOOPに特有のものではないのは確かなのですが。＃でも関数もオブジェクトに見えちゃうんだな、俺の目には。
• ところで、本当に何の仮定も置かなければ、データを扱うことが出来ないのでわ。
  • いつどこでどの操作を提供すべきか？というのを自動化しようとしたら、OOPになったのかも。
• あと、「部品」は「操作」とは限らない。まずそれが「有る」こと、なにかを「保持」してること、がその部品の役割であることも…(と恒例の話題)

shiro :

ここでのOOは言語の話ではなくて、モデリングやデザインの話です。 （だって関数指向とオブジェクト指向を混ぜる話になってるでしょ。 FPと言ったのがまずかったか）。 Java, C++はクロージャ相当のものがすごく書きにくいため混ぜにくいんですが、 ブロックを持つ動的なOOPなら両方の書き方が可能ですし、 そういう前提で話をしています。 で、OOPでも汎用的なライブラリにしようとすればするほど、 ブロックを多用する傾向があるんじゃないかなあと。 respond_to? でディスパッチする(=データにいちいち問い合わせる)より、 ブロックで渡してもらう(=操作を外部から提供してもらう)方が 綺麗だし柔軟性があるよなあと。 C++でもtemplateを多用してゆくとどんどんそっちの(関数的な)方向に向かうんじゃ ない?

ここで言っている関数指向では、あるデータを扱うある操作Aを実装しようとしたとき、 データに対して仮定を置くのではなく、操作Aを実装するためにデータに対して 必要となる操作B, C, ... を呼び出し側から提供してもらう、ってことです。 データに対する仮定は間接的に操作B, C,...により与えられますが、 操作Aにしてみれば、そもそも最初からデータが分離可能な形で 存在しなくたって構わないわけで。

(例えば、「木構造」が単なる2つの整数の配列でC[i]とS[i]で表されているような場合を 考えてみよう。ノードは単に整数のインデックス k で表現される。 C[k]はノードが子を持てば最初の子のインデックスを保持し、そうでなければ -1を保持する。S[k]はノードの次の兄弟へのインデックスか、兄弟が なければ-1を保持する。このデータ構造に、ルートノードのインデックスが 与えられれば、これは立派な木構造だ。 さて、WiLiKi:Scheme:オブジェクト指向表現の関数版tree-walkをこの構造に 適用するのは簡単だ。リンクトノードで表現された木の場合と何ら変わるところは ない。一方、tree-walkが、渡されたノードに対するメソッド呼び出しを使う、 よくあるOOベースで作られていたらどうなるだろう。何らかの中間オブジェクト、 一時的なオブジェクトが必要になるのではないか。それは、クロージャが自動的に やってくれることを手動で模倣することになるだろう)

「何かが有り、何かを保持している」ことをモデル化するには、 その「何か」の見方を決めなければならず、そういう見方は既に アプリケーション依存なんじゃないか、ということです。 だから、アプリケーションから出発する場合はOOモデリングはうまく機能するけど、 具体的なアプリケーションとは独立して部品を作るなら、操作中心に ならざるを得ないのでは。

なお、私は Object == Closure (mod Syntax) な立場ですので、 あるものがオブジェクトか関数かを分けることはできないと考えています。 設計の段階で、どっち側から見るのが便利か、という話をしてます。

ささだ :

読んでいて generics なんてのを思い浮かべました。