ToDo:
色んな論点があって何が何やら。おもろい。
個人的には、楽できる、ってのはそりゃまぁわかるんだけど、 interface のドキュメント能力に比べて はるかにどうでもいいなーというだけのことが、 元は言いたかっただけなので、 まぁ duck typing のメリットを説明してもらっても 説得されない感じかなーと思いました。
そしてまぁ僕のそのドキュメント能力についての文句は、 たぶん const とかの話と一緒で、 結局まぁ動的言語でデカいもの書きたくねーって言ってるだけにすぎないので、 まぁ言語機能とかを議論してる人には面白くない論点で ごめんなさいという感。
いつも言ってるんだけど、 会社で Python 書くのが楽しくなかったんだよね。 duck typing なはずなのに document 書かんと使い方伝えられないし、 これならいっそきっちり型書かせてくれーという。
さて、本題のだっくたいぴんぐの各論について、 どうでもいい思ったことをそこはかとなく。
http://shinh.skr.jp/m/?date=20100914#c01
interface 多すぎーってのは、 うーん本当にそうかなぁ。 Serializer ってクラスがあるなら Serializable 作らにゃならんのはそうなんだけど、 しかしまぁなんでもかんでも用意する必要は無いんじゃないかなー的な。 なんか標準ライブラリ内に実際に 同じ interface を使うものが複数無い場合は、 まぁ作らんでいい、みたいな基準くらいでいいんじゃないかなぁ。 Java なんかはまぁ、頑張った結果だろうけど、 ありそうなものがあるんじゃないすかねえ。
interface の例として、 Runnable みたいなのがあると思うんだけど、 Ruby の proc って proc like なもの作ったとして、 はて Proc#call を用意すればいいのか Proc#[] を用意すればいいのか… みたいな、まぁドキュメント頼らにゃならんなら、 最初からコードに interface 書きゃいいじゃんねえ的な。 まぁ他の人も言ってる話だけど。
http://shinh.skr.jp/m/?date=20100914#c04
後から interface …って話は、
http://twitter.com/yukihiro_matz/status/24542099876
にある通り Go のアレはそいうのできた…と思う。自信ないが。
http://shinh.skr.jp/m/?date=20100914#c09
は respond_to? とか使ったらそれこそ duck typing の良さってか動的型付けの良さが 失われちゃってる感があるなぁ。 Guido がそういうのはやっちゃダメって言ってた気がする。
ああ matz 先生も言ってる。
http://twitter.com/yukihiro_matz/status/24545594351
あと、そうそう、 duck typing いらねーいらねー言っておきながら、 一個致命的に重要な用途を思い出したのだった。 何かっつーと unit test のための mock というやつ。 あんなもんのために interface とか書きたくない。
(03:46)
最初の、
個人的には、楽できる、ってのはそりゃまぁわかるんだけど、 interface のドキュメン ト能力に比べてはるかにどうでもいいなーというだけのことが、元は言いたかっただけ なので、まぁ duck typing のメリットを説明してもらっても説得されない感じかなーと 思いました。
はひどい後付けだなー。
昨日の段階では
色々考えた結果、 interface を書かなくていいという type 数節約よりも、 interface のドキュメントとしての価値の方が重く見てるんだろうなぁと思った。それと同時に、 duck typing は別にメリットとか無くて、動的型だからしょうがなくやってるだけなん じゃないかと思えてきた。
とか言ってるんだから…
まめさんごめんなさいごめんなさいごめんなさい…
(03:53)
LL っていうけどホントに lightweight なんだろうかー ってのはちょっとイベントとして面白い気がする。 なんか例えば、 C++ と Ruby の人が適当に、 codegolf.com くらいの規模の問題を 10 問程度解いていって、 どっちが早く終わるか、みたいな。 ああでも duck typing とか登場させるならもうちょい規模大きいべきか。 こいう仕様の wiki 作ってくださいーとかそんくらいすかね。
LL イベントとかでやるといいんじゃないかな。 そのイベントでコード書く人はイベントそっちのけで ずっとコード書いてて、 途中で時々進捗聞いたりするとそれぞれの言語の良いとことか 見えたりするやもしれず。
しかし、回答者のレベルをそろえるのはむつかしそうである…
(04:00)
http://shinh.skr.jp/m/?date=20100916#c02
自分の spam filter を突破できなくてコメント書けないぞ…
> duck typing なはずなのに
「duck typing だから型書かんでいい期待があるのに、結局 document に型書いてるようわーん」という話でした。途中はしょってましたすいません。
http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py
とか見ると、
Args: filename: str, the name of the input file. raw_line: str, the line of input text, with comments. linenum: int, the number of the current line. error: function, an error handler.
とか書いてて大変悲しいわけです。
> is_a? と respond_to?
ああ is_a? はたしかに論外ですね。ただ respond_to? 使うのも、実際はたいして問題にならないことのために (respond_to? で調べて runtime error 出しても、ほっておいてメソッドが無いっていう runtime error が出るのもたいしてかわらない) 動的言語の気軽さみたいなのが損われるという意味で、イマイチなんじゃないかなぁと。
> # 実は大して興味ないはずのこの話題に、どうしてぼくは長文をつっこんでいるのだろう……
ブログ炎上させたい場合はスキのある文章で人の好きな物を批判するといいみたいですね。
(13:52)
| 前 | 2010年 9月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | ||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
> duck typing なはずなのに document 書かんと使い方伝えられないし、 これならいっそきっちり型書かせてくれーという。
超同意ですね
> duck typing なはずなのに document 書かんと使い方伝えられないし
「duck typing だから document 書かなくていい」という期待があったのか。それは考えたこともなかったです。
「duck typing → typing →型付け→静的型付けはドキュメント書かなくていい」という発想？
少なくとも静的型付けのない言語だと、ドキュメント書かないと duck typing の意図は通じないですね。
ソース読んでも、たまたま foo しか呼んでいないのか、duck typing を許す意図があるのかわからないですし。
作者にその意図がなかったら、将来的に変えられちゃうかもしれない。
> Ruby の proc って proc like なもの作ったとして、 はて Proc#call を用意すればいいのか Proc#[] を用意すればいいのか…
proc-like なオブジェクトを使うコード次第だと思います。
どこでどう使うか想定できないなら全部模倣すべき。StringIO みたいに。
> ドキュメント頼らにゃならんなら、 最初からコードに interface 書きゃいいじゃんねえ
そうなのかなあ。
duck typing は「メソッドを実装している」だけでなく「そのメソッドが仕様通りに動く」まで求めてると思う。
だから結局ドキュメントは必要な気がします。
あ、duck typing なメソッドでいちいち書かず、interface 一箇所でドキュメント書くだけでいい、という意味？
それはあるかも。
ちなみに Ruby で現実に使われてる duck typing は、
- each や to_s みたいに、名前と挙動の対応が広く認識されてるメソッドを使うのでドキュメントほぼ不要
- StringIO と IO みたいに全メソッド模倣してクラス作者が本気で騙そうとしている
のどっちかになってる気がします。
> respond_to? とか使ったらそれこそ duck typing の良さ
is_a? と respond_to? は別です。respond_to? は duck typing そのものなので問題ないはず。
# 実は大して興味ないはずのこの話題に、どうしてぼくは長文をつっこんでいるのだろう……
＞ # 実は大して興味ないはずのこの話題に、どうしてぼくは長文をつっこんでいるのだろう……
それがshinh先生マジックなわけです。
＃過去なんどか経験があるのでＡＣ
> 「duck typing だから型書かんでいい期待があるのに、結局 document に型書いてるようわーん」
えーと、「duck typing だから」じゃなくて、「動的型付けだから」？
Python の例も duck typing 関係ないような。raw_line は str しか受け取らない気満々に見える。
まあ、型はすばらしいドキュメントですよね。
> respond_to? 使うのも、(略) イマイチなんじゃないかなぁと。
はい、面倒なだけだと思います。
「と」さんの言っていた本当の問題は、「必要なメソッドを実装しているか確かめたい」ではなく、
「必要なメソッド一覧を (できれば機械的に) 把握したい」ということだと思ってました。
> ブログ炎上させたい場合はスキのある文章で人の好きな物を批判するといいみたいですね。
うう、ごめんなさいごめんなさい。
動的型の話が混じっててすいません。
Python の例は例えば、 filename はエラー報告時に %s に渡してるだけなので、 __str__ が適切に定義してあればまぁなんでも動くはずなんですが、わざわざコメントに str って書いて str しか受ける気ありませんよーって言ってるにもかかわらず、普通に int とか受けれちゃうとかが、まぁちょっと悲しいとかそういう。
必要なメソッド一覧を機械的に把握、ってのは面白そうな課題に思えますね。 document generator みたいなことできれば面白げ。たぶん id:soutaro さんの研究とかそいう方向にも使えたりせんのかなー的な。
炎上については適当に文章書いててこっちがごめんなさいごめんなさいごめんなさい…です。