C#の拡張メソッドとScalaの暗黙の型変換について

ufcppさんの考える理想系についてkmizuさんがヒアリング、みたいな構造
16
++C++; // 管理人: 岩永 @ufcpp

@kmizu 単にインターフェイス相当のものが実装持てるだけだと、直行性に書けるというか。規約決める人とアルゴリズム書く人は別になりうるのに、一緒にしてどうすんだと。

2012-01-09 03:07:12
++C++; // 管理人: 岩永 @ufcpp

@kmizu C# の拡張メソッドですらきわどいですからねぇ、静的に制御されてるって言っても。あれは、静的メソッドだからかろうじてセーフだと思っていて。ああいうのは、pureな関数でないといまいち。

2012-01-09 03:10:11
kmizu @kmizu

@ufcpp ちょっと問題意識がよくわかりません。Javaのインタフェースがデフォルト実装を持てるようにする拡張は、インタフェースへのメソッド追加がクラスファイルレベルでバイナリ互換性を破壊しないようにする(クライアントに影響を与えないようにする) 機能だと認識しています。

2012-01-09 03:10:36
kmizu @kmizu

@ufcpp ふむー。C# の拡張メソッドでもきわどい、という論点なら、確かに Scala の暗黙の型変換を危険視するのはわかる気はします。静的メソッド~以降の趣旨がよくわかりませんでした。静的メソッド = pure 関数、というわけでもないですよね?

2012-01-09 03:14:10
++C++; // 管理人: 岩永 @ufcpp

@kmizu 個人的には、拡張メソッドでpureでない実装するのはアウト。

2012-01-09 03:16:32
kmizu @kmizu

@ufcpp ふむふむ。なるほど。規約としてそうすべき、という話ですね。それだとすると、Scala の implicit conversion も対してあまり差が無いような。pureでないメソッドも追加できますが、それは拡張メソッドでも同じですし。

2012-01-09 03:18:18
++C++; // 管理人: 岩永 @ufcpp

@kmizu デフォルト実装は、害はなくて、単純にそれじゃ不足だと思っています。インターフェイスのソースコードを触れない人がアルゴリズムを用意できないといけない。

2012-01-09 03:24:37
++C++; // 管理人: 岩永 @ufcpp

@kmizu 型変換だと、インスタンスメンバーすら追加できてしまうのが微妙なんですよねぇ。あと、個人的には、あれのイメージはメンバーの追加じゃなくて、どちらかというとPowerShellのfilterなので、静的でないと、という。

2012-01-09 03:27:33
kmizu @kmizu

@ufcpp なるほど。インタフェースのデフォルト実装は、インタフェースのソースコードを見られない人が後付けでメソッドを追加できないのがダメだ、と。それは理解できます。

2012-01-09 03:28:56
kmizu @kmizu

@ufcpp うーん。インスタンスメンバーを追加する使い方は実際の所 Scala ではほとんど無いと思います。特に、メソッド追加のために使用するとき、暗黙変換オブジェクトは揮発性なので、すぐ消え去りますし。

2012-01-09 03:30:25
kmizu @kmizu

@ufcpp hmmm。しかし、実際の所、あれの実用上の使い方は、メンバーの追加に関する用途がかなりを占めています。Scala 2.10でもその辺りをより簡単に書けるシンタックスシュガーが用意されますし。あとは、静的メソッドでないと、辺りが論点でしょうか。

2012-01-09 03:32:22
kmizu @kmizu

@ufcpp 後付けで追加するメソッドは静的メソッドでないと、というのはちょっと理解できていないので、説明いただけると助かります。Scalaだと静的メソッド追加(静的メソッドがScalaにそもそも無いですが)だと色々なライブラリが成り立たなくなるので、実際には無理ですが。

2012-01-09 03:34:31
++C++; // 管理人: 岩永 @ufcpp

@kmizu 実質そうなんですけどね。最初から禁止しとけよと…

2012-01-09 03:37:04
++C++; // 管理人: 岩永 @ufcpp

@kmizu うーん、個人的に思ってる理想形は、F# の|演算子なんですよねぇ。単に、関数呼び出しの語順を入れ替えるだけ。あれが理想です。

2012-01-09 03:37:42
kmizu @kmizu

@ufcpp 仕様的な観点から言うと、デフォルトで禁止されないのが直観的(というか余計な仕組みを入れな場合)の動作なので、あえて「××の場合禁止」というのを言語仕様に組み入れにくい、という事情はありますかね。Scalaの場合は。

2012-01-09 03:44:28
kmizu @kmizu

@ufcpp ただ、言語仕様的にそこがどうか、というのはともかく実用上はその点はあんまり問題にならないかなと。どちらかというと、拡張されたメソッドを探索しにくいのが問題な気がします(最近のScala IDEはこの辺わかるようにしてくれますが)。

2012-01-09 03:45:50
kmizu @kmizu

@ufcpp なるほど。その場合、オブジェクトにメソッドを後付けで追加する、というより、データ | 関数呼び出し | 関数呼び出し みたいな語順で書ける事が重要、という理解でいいでしょうか?

2012-01-09 03:47:51
++C++; // 管理人: 岩永 @ufcpp

@kmizu 型変換でやっちゃうからそういうことになるんだと思うんですよねぇ。最初から、F# みたいに、関数の語順置換でよかったと思うんですよ。

2012-01-09 03:48:01
kmizu @kmizu

@ufcpp F#みたいな関数の語順置換だと、そもそもベースがオブジェクト指向言語であるScalaとは激しく相性が悪そうな気がします。もうちょっと良い手はあったかもしれませんが、ScalaだとF#方式は取りづらそうな。

2012-01-09 03:50:08
++C++; // 管理人: 岩永 @ufcpp

@kmizu そう、結局、LINQって関数型なんですよ。まあ、Scalaだってmixedパラダイムなんだし、そこはOOPにしない方が良かったと思っています。

2012-01-09 03:57:12

語順とOOPについてのコメント

neuecc @neuecc

LINQはIntelliSenseなのでメソッドチェーンでOOPが生きるなあ、とは思いますです。Namespaceで追加される拡張メソッドはデッキ。時に気の向くままに切り替えるのも風情がある。と、先のNyaRuRuさんの記事見て再確認。

2012-01-09 05:13:44

++C++; // 管理人: 岩永 @ufcpp

@kmizu そうです、語順以上の問題にしない方が設計としていいと思っています。インスタンスメンバーを後から足すとか、型を変えるとかは大げさ。

2012-01-09 03:58:06
kmizu @kmizu

@ufcpp なるほど。仰りたいことが理解できた気がします。ただ、(言語仕様的な) 出自が関数型言語に近いF# とオブジェクト指向言語である Scalaとう違いがあって、そういうアプローチは F# だからこそ取れたんじゃないかと。

2012-01-09 03:59:58