[#8468] require で SEGV — ruby <g96p0935@...>
西本です。
[#8469] [PATCH] -s command line option — nobu.nakada@...
なかだです。
[#8507] mode_t in file.c — Katsuyuki Komatsu <komatsu@...>
小松です。
[#8530] Enumerable and rand — Koretsugu Daigoro <tmmcross@...>
これつぐです。
まつもと ゆきひろです
これつぐです。
まつもと ゆきひろです
原です。
まつもと ゆきひろです
原です。
ごとけんです
これつぐです。
[#8565] interface declaretion — "Dai.K." <MAP2303@...>
[#8581] Re: [ruby-list:19228] Ruby 1.4.3 — Katsuyuki Komatsu <komatsu@...>
小松です。
まつもと ゆきひろです
えぐち@エスアンドイー です。
小松です。
まつもと ゆきひろです
小松です。
[#8622] Win32API (Re: Ruby 1.4.3 binaries for Cygwin and DJGPP) — WATANABE Hirofumi <Hirofumi.Watanabe@...>
わたなべです.
有馬@FITECです。
よしだです
[#8623] [BUG?] core dump `ruby -r debug' — IWAMURO Motonori <iwa@...>
岩室@富士通です。
[#8635] slow gsub — WATANABE Hirofumi <Hirofumi.Watanabe@...>
わたなべです.
[#8645] urllib and httplib — TAKAHASHI Masayoshi <maki@...>
高橋征義です。
なひです.
高橋征義です。
なひです.
まつもと ゆきひろです
なひです.
青山です。
なひです.
高橋征義です。
まつもと ゆきひろです
高橋征義です。
なひです.
西@九大です。
なかだです。
あおきです。
[#8650] [PATCH] Ruby/Tk — Koji Arai <JCA02266@...>
新井です。
新井です。
新井です。
新井です。
永井@知能.九工大です.
新井です。
永井@知能.九工大です.
新井です。
新井です。
[#8665] [mswin32] STDERR does not work during `_function. — "NAKAMURA, Hiroshi" <nakahiro@...>
なひです.
金子です。
金子です。
[#8667] make symlinks around libruby.so in instruby.rb — akira yamada / やまだあきら <akira@...>
[#8692] [win] dir name — KANEKO Naoshi <wbs01621@...>
金子です。
小田@QNES です。
えぐち@エスアンドイー です。
小田@QNES です。
えぐち@エスアンドイー です。
なかだです。
小田@QNES です。
えぐち@エスアンドイー です。
小田@QNES です。
[#8705] [mswin32] 100% CPU usage when use sleep — Katsuyuki Komatsu <komatsu@...>
小松です。
まつもと ゆきひろです
小松です。
[#8722] [mswin32] Win32API — KANEKO Naoshi <wbs01621@...>
金子です。
小松です。
まつもと ゆきひろです
[#8741] Re: [ruby-list:19945] Re: array + empty string — Wakou Aoyama <wakou@...>
青山です。
まつもと ゆきひろです
青山です。
まつもと ゆきひろです
ごとけんです
まつもと ゆきひろです
なかだです。
まつもと ゆきひろです
[#8742] [REQ] Array#each{|a,b,...|}, Array#shift/pop(num) — Kazunori NISHI <kazunori@...>
西@九大です。
まつもと ゆきひろです
西@九大です。
まつもと ゆきひろです
西@九大です。
まつもと ゆきひろです
えぐち@エスアンドイー です。
西@九大です。
あおきです。議論も好き。
西@九大です。
あおきです。
まつもと ゆきひろです
有馬です。
knuです。
まつもと ゆきひろです
これつぐです。
knuです。
まつもと ゆきひろです
あおきです。
まつもと ゆきひろです
In message "[ruby-dev:8792] Re: [REQ] Array#each{|a,b,...|}, Array#shift/pop(num)"
まつもと ゆきひろです
ごとけんです
ごとけんです
なかだです。
ごとけんです
[ruby-dev:8574] Re: [REQ] {enumerable, integer, range}.rand
まつもと ゆきひろです
In message "[ruby-dev:8569] Re: [REQ] {enumerable, integer, range}.rand"
on 99/12/07, Kazunori NISHI <kazunori@swlab.csce.kyushu-u.ac.jp> writes:
|今迄の話の流れと結論、そしてこのメールの位置付けです。
|
| * Kernel#rand(min..max)/(min, max)? ⇒ よさそう
| * Array#random_get ⇒ よさそう(名前次第?)
| * Kernel#rand(obj) ⇒ ダメ ⇒ 何でさっ!
最初のはまだ私の中で結論出てません。rand(obj)よりは抵抗少な
いけどね。
|まず、「名前問題」は無視しています。あと、立場的には、RandomGenerator
|が複数存在しなくても、「乱数源」というオブジェクトに対するメッセージ、
|という意味で(統一的な窓口の)存在価値はある、です。で、思想的な話です。
存在価値がゼロでないことは肯定します。どこまであるか、でしょ
うね。
|From: matz@netlab.co.jp (Yukihiro Matsumoto)
|> (3) メソッド型(obj.random_get)よりも関数型の
|> API(rand(obj))を選ぶ理由が無い
|
|意見の食い違いはどうもここらへんの思想の違いにある予感。。。私は、
|
| * obj.random_get を持つ複数のクラスがあるなら、それを統一的に受ける
| 窓口があってもよい。(double dispatch なので、obj.random_get が前提。
| それを捨てて rand(obj) だけ、という意味ではない)
|
|と考えています。その為の double dispatch であると。で、何でこれが反対
|されるのだろう?と思っていたのですが、まつもとさんの異論は直接これに向
|けられているのでなく、
|
| * その窓口がなぜ関数(型)でなければならないのか?
|
|という事なのですか?
そうです。ただし、
| (RandomGenerator#rand/random(obj) とかなら許せる)
ではありません。関数的に見えた方が自然なものは関数的に見えた
方が良く、メソッド的に見えた方が自然なものはメソッド的に見え
た方が良いというのが私の一貫したスタンス(のつもり)です。
で、「あるcollectionのランダムな1要素を選択する」という機能
は、collectionのメソッドとして見えた方が自然だと私に思えると
言うそれだけのことです。
次に、かずのりさんの主張である
| * obj.random_get を持つ複数のクラスがあるなら、それを統一的に受ける
| 窓口があってもよい。(double dispatch なので、obj.random_get が前提。
| それを捨てて rand(obj) だけ、という意味ではない)
ですが、「統一的に受ける窓口」とはなんで、なんのためであろう
かという疑問が残ります。
(概念としての)ある処理をまとめる方法は、オブジェクト指向言語
にはダイナミックバインディングがあります。つまり、おなじメソッ
ド名と引数パターンを持つメソッドは、それらが別々のクラスで定
義されていても同様に呼び出せるというアレです。統一的な窓口メ
ソッドを用意する必要はなく、名前(プロトコルあるいはシグナチャ)
を統一するだけで済みます。
double dispatchは「メソッドはひとつのオブジェクト(レシーバ)
によって選択されるが、ふたつの(かなり無理すれば複数)のオブジェ
クトの組合せによって処理を選択したい」というニーズに対する従
来型オブジェクト指向言語による解です。
しかし、今回は別に乱数発生源とcollectionを組み合わせて選択す
るというニーズが存在しないので、わざわざdouble dispatchを選
択する理由も、そのためのくくり(Kernel#rand)を導入する必然性
もありません。
さらに現在既にKernel#rand()は「1個の整数を引数にとる」という
仕様になっていますから(これを変えるつもりはない)、これに統一
的な意味を与えるためには、必然性が良く分からないdouble
dispatchを使って、
def rand(obj)
obj.get_rand_value(drand48)
end
のようなことを行うか、将来の拡張性などに不安を感じつつ、型に
よる分岐を行うかということになりそうです。これは嬉しくない。
これらの「嬉しくなさ」、つまり
* 関数のように思えないものを関数的にする
* 必然性の感じられないdouble dispatchを導入する
などを払拭させてくれるだけのメリットが感じられないというのが
反対の理由です。しかも、反対することによってかずのりさんから
楽しいフォローがいただけると言うオマケつき。
# この忙しい時期になにやってんだか。
|最初から気になってたんですが、なぜ「メソッド型」や「関数型」と区別する
|んでしょうか?私は全く区別なく、ruby は全て「メソッド型」だと思ってい
|ます。ruby スクリプト(のメイン部分?)は暗黙的に「include Kernel」され
|た状態であると考えています。
「外見」からです。外見は重要です。
まつもと ゆきひろ /:|)