単一責務原則（SRP）から始まるFPとOOP

kmizu @kmizu

@uehaj ちなみにここでscalazは関係ないです。むしろ、OOP/FPのOOPの部分をあまり活用してないのがScalazだと思うので。

uehaj @uehaj

.@kmizu インスタンスメソッドは「暗黙にthis」が渡り、継承+overrideによる遅延束縛がなされることを除き、staticメソッドと等価という認識です。このthisとの結びつきのと継承のはなしの2点が、fpの思想と直交なのか

uehaj @uehaj

.@kmizu あ、scalazの例は、もし本当にfpとoopが並存し両立して両者の利点が加算できるなら、oopも最大限使ったscalazが存在できるはず、なぜそうでないか、という意図で挙げました。

kmizu @kmizu

@uehaj はい。インスタンスメソッド関する認識は同じです。そのうえで、それはfp(≠fpl)直交しているのだという主張です。実例はScalaのimmutable collection libraryです。

uehaj @uehaj

.@kmizu 了解です。たいへん参考になります。

uehaj @uehaj

.@kmizu fpの定義がそうなら確かにそうですね。あとはoopl機能は不可欠なのか不要なのか。実は継承は不要で多相型や型クラスでことが足りるのか。両立が可能として、その意味するところを理解したいです

kmizu @kmizu

@uehaj それはより詳細な議論が必要な問題ですね。ちょっとこれから #ScalaMatsuri2014 MTGがあるのでまと後でよろしくお願いします。

uehaj @uehaj

.@kmizu はい、適当によろしくお願いします。

uehaj @uehaj

ちなみに元ネタはこちらです「単一責任の原則とインターフェイス分離の原則の2つを適用すると、単一のメソッドだけを持つ、粒度の細かいインタフェースやクラスが..増え…その時点でF#のような関数型プログラミング言語に移動する」http://t.co/D649kgLxyy

uehaj @uehaj

scalaでは構造的部分型ができるのか。なんでもありだな

uehaj @uehaj

Java8 Streamの設計者は、悪いと考えたのであろう RT @uehaj: 単一責務の原則を疑いたい。ListにeachがあるのはSRP違反だ。で、なにがわるいのだ。

kmizu @kmizu

@uehaj なんとなく話の続きですが、fpの話でしたらoopl機能は継承も含め不要で話が終了すると思うので、object functionalな話と仮定します。その文脈だと継承は必要かどうかは微妙で、とにかくオブジェクト（メソッドを持つもと）とサブタイプがあれば十分な気はします

kmizu @kmizu

@uehaj あ、これは静的型付きを前提としていますが、nominal/structural のどちらのsubtyping schemeを選んでもかまわないと思います（ScalaはJavaがnominalな型システムなのでそっちの方向に倒したのだと思います）

kmizu @kmizu

@uehaj 両立が可能だというのは、たとえばこういうコードが現実的に意味があるという話です（Scalaのコレクションライブラリより） val s: Seq[Int] = List(0, 1, 2, 3) val q = s.filter{_ % 2 == 0} #scalajp

kmizu @kmizu

@uehaj ここで、List[T] <: Seq[T]がなりたち（サブタイピング）い、SeqもListもfilterメソッドを持ちます。実行時のクラスによって適用される操作が決定されますが、コレクションは変化しません（不変性）。 #scalajp

kmizu @kmizu

@uehaj うまく表現できていませんでしたが、(1) サブタイピング + 動的ディスパッチ (2) オブジェクトの不変性の両方を満たせるところに、object functionalのうまみがあると個人的には思います。そして、その良い例がScalaのコレクションライブラリです。

kmizu @kmizu

@uehaj ちなみに、型クラスはコンセプト的にはそもそもfpにすら（直接の）関係はなくて（研究的には関数型プログラミングの研究から派生している面がありますが）、「よりad hocでない」ad hoc polymorphismを実現するものにすぎないです。

Kota Mizushima @kmizu_en

@kmizu @uehaj 直接の関係はないはちょっと言いすぎだったかもですが、あくまでadvancedな機能であるという話です。実際、Standard MLやOCamlに型クラスはありませんし…。

uehaj @uehaj

.@kmizu ありがとうございます、今ちょっと時間がなくちほど考えさせてもらいますm(..)m

kmizu @kmizu

@uehaj いえいえ。お時間のあるときにでもまた適当にりぷらいもらええれば。

uehaj @uehaj

.@kmizu Immutableなデータに対して副作用を持たないメソッドで処理を完遂させようという意味でのFPは、OOPと対立しない、というのはたいへんに了解しました。

uehaj @uehaj

.@kmizu ただ、FPは、それを体現しようとするFPLにおいて、特長と意義を拡大するための発展的運用が考案されてきました。例えば、高階型、遅延評価、高度な静的型体系(多相型)、型クラス(ご指摘通り)、…

uehaj @uehaj

.@kmizu これらはFPと組み合わせることで、実際にシナジー効果(死語)を発揮するわけですが、組合せる言語機能多種多様であり、何かが必須条件である、という共通認識があるわけではありません。(高階関数は必須かな)

uehaj @uehaj

.@kmizu また、ある見方からすると、FPと組合せることでその効果を発揮させよう、という対象に「OOP」を選んだのがScalaなのでしょう(これは余談)。

uehaj @uehaj

.@kmizu 元の私のテーマというかは、「FPとOOPの関係性」でありました。それぞれのパラダイムを構成する要素を分解し、個々に比較して、それぞれが、対応するのか、置換になるのか、対立するのか、などなど。