rubyを語るスレッド 3

松本さんがどこかでインクリメントの
foo++
というスタイルはオブジェクト指向になじまない、ということをおっしゃっていたと思うのですが、
その理由はなぜですか?

何を足すの?

>>573
0++ の結果がどうなるかを考えてみよ

obj.succ があるんだから obj++ があっても良さそうな気がするが。

obj++ があるとすれば obj.succ! だが 0.succ! ってなんじゃろうという話かと。

それをいうなら 0+=1 だって出来ないのに += という構文はあるわけだが

>>578
変数とオブジェクトは違うんだが。

>>577
0.succ! は 1 になるのは自然だと漏れは思うのだが、それは変？

0.succ == 1は当然だが、succ!だと0自体が1に変わるってことになるだろう。

>>579
++ をメソッドに割り当てる必要があるかということなんだが。
a += b が a = a + b という構文に割り当てられているのだから
a++ を a = a.succ などの構文に割り当てるという規則があっても
不思議ではない。

イラネ。

a++ が a = a.succだと、
オブジェクトaに、++というメッセージを送ると、
新たに生まれたaによって置き換えられる
っていう意味?

>>581
それのどこが変なの？

＃ Ruby の実装上 Integer#succ! がありえないというのはひとまず置いといて、

>>585
id = "a".id ; ObjectSpace._id2ref(id).succ! ; p ObjectSpace._id2ref(id) #=> "b"

では、もし Integer#succ! があった場合、以下はどうなるべきと思うのか？

id = 0.id ; ObjectSpace._id2ref(id).succ! ; p ObjectSpace._id2ref(id)

>>584
少なくとも += はそうなっている。
ruby -e 'a = "a" ; p a.id ; a += "b" ; p a.id'

>>586
#=> 1

mutable integer は論外だろう。
++ がない理由としてしばしばあげられるのは、
++ がオブジェクトでなく変数に対する操作を表す構文であるいうことだが、
それは、+= のように変数に対する操作を表す構文がすでにあることを擁護しない。
++ を採用しないのは単に好みの問題であって、
オブジェクト指向と相性が悪いということではないと思われ。

>>587
それは知っている。
というか、知ったときに、騙されたと感じた。

>>590
しかし += が新たなオブジェクトを持ってくることがなければ
integer を mutable にする必要があるのでは？

mutable integer ってなんじゃらほい？

mutable な integer のことでわ？
オブジェクトは mutable と immutable に分類される。

>>593
ぐぐってみて、mutable と immutable はなんとなくわかりますた。

で、>>589 の「mutable integer は論外」っていうのが良くわかんねす。
「Ruby では mutable integer はありえない」ってことなのか、
「そもそも mutable integer なんてありえねー」ってことなのか？

>>594
> 「そもそも mutable integer なんてありえねー」ってことなのか？

こっちかと。

>>591
その通り。
で、integer は mutable じゃないので、+= で新しいオブジェクトが出来る。問題なし。
でも、587の例は、stringでしょ。
+= は、concat!だと思っていたけど、a = a + "b"のsyntax sugarだと知って、騙された気分。

+=が、integerとstringで同じ動作をすべきという考えもあるけど、
私の心の中のstringに対する+=は、concat!だったのよ。

>>596
つまり、「仕様が俺の思い込みと違う。騙しやがったな。」という話しでつか？

>>596
むしろ += を再定義出来ないことが不自由に感じることはある。
コンテナでは += を破壊的にしたいことはあるから。
だが += を再定義出来ないことが前提なら解釈を一律にしておくのは妥当な仕様だろう。

>>597
ｻｸｰｼｬは驚き最小という言葉に甘んじているからそういう話もありと思われ

>>597
いえーす

>>595
あ、そうそう。そっち。

>>601
それはなんでなんでしょう？

整数はあくまで整数であって整数のコンテナではないから。

逆に聞くが、
もし Integer が整数のコンテナだったとしたら、その中身は一体何じゃらほい。

>>604
ん〜、わかんないけど、数値みたいなもんなんじゃないの？
String が mutable なんだったら、
別に Integer が mutable だったとしてもそんなに変とは思わないんだけど・・・

>>605
むー、正直そんなことをいう人には初めて会った。
円周率に PI という名前をつけて、更に a = PI によって a に代入していたとする。
もし数が mutable なら a.replace(3) などとすると、その世界では PI == 3 に
なっちゃうわけだが、そういう可能性があっても面倒ではないと考えるのね？

なんかこの議論、つい最近どっかで見たことがあるだけど、どこだっけ……。

>>606
むしろ、それがいいところなんじゃないのかな？
将来、

　　 【衝撃】πの真の値は 3 だった！！【激震】

なんてことが起きても大丈夫。(w
円周率はともかく、物理定数の正確な値が求まったとか……。よー分からんけど。

当然前提として、

a = 3; b = 3
a == b #=> true
a.equal?(b) #=> false

にならなアカンやろけど。

bigdecimal は以前 mutable だったというウワサが

>>607
> なんかこの議論、つい最近どっかで見たことがあるだけど、どこだっけ……。
ほんとに最近か? 昔のFORTRANがそんなだと思ったが。

>>606
ちょっとまって、それは詭弁ではないですか？

> 日本国に JP という名前をつけて、更に a = JP によって a に代入していたとする。
> もし文字列が mutable なら a.replace("韓国") などとすると、
> その世界では JP == "韓国" になっちゃうわけだが、
> そういう可能性があっても面倒ではないと考えるのね？

String なら実際にこういうことが起こっているわけですが、
Integer だとこうではいけないという主張の、
本質的な理由が知りたいわけです。

>>607
> 円周率はともかく、物理定数の正確な値が求まったとか……。よー分からんけど。

それはコードを書き換える必要があるので、実行中に値が変わることとは別の話。

> a.equal?(b) #=> false

mutable/immutable と immediate value か否かも別の話。
immediate value にするかどうかは実装の都合に過ぎないよ。

p 3.0.equal?(3.0)
p 3.equal?(3)
p ((10**10).equal?(10**10))

>>610
待て、国を文字列でreplaceするのは反則だろう。

3.replace(4)としたら、1+2が4になって欲しいわけか。

>>613
そんなことは誰もいってないと思うけど？

Integerをmutableにするというのは、意味的にはそういうことだ。

>>613
いや、Integer が「整数のコンテナ」になって欲しい、ので、1+2 はやっぱり 3 です。

というか、>>611 を読んで、自分が相当変なこと言ってる気がしてきました。
「immediate value」って初めて聞く言葉なんですが、
「Ruby 用語集」の「即値」のところの話しですよね。
うーん、よう分からんようになってきた。頭冷やして出直してきます・・・

>>611
> >>607
> > 円周率はともかく、物理定数の正確な値が求まったとか……。よー分からんけど。
>
> それはコードを書き換える必要があるので、実行中に値が変わることとは別の話。

なぜコードを書き換える必要があると？
# 本題でないのでスルーしてね♥

> > a.equal?(b) #=> false
>
> mutable/immutable と immediate value か否かも別の話。
> immediate value にするかどうかは実装の都合に過ぎないよ。

書き方が悪かった。immediate value かどうかを問題にしたつもりじゃなかった。

a=3; b=3;
a.replace(4)
b #=> 3

にならないと困るよね、ってこと。

>>604

ビットのコンテナ

整数というのは代数と順序で定義された対象だから
それをどれだけ反映するかを前提にしてるんじゃないかな。
整数変数ではなく整数をプログラミング言語で表現するなら
mutable というのは全く考えられない。

しかし文字列もそうなんだけど、Cプログラマのmatzには
文字列の数学的性質に馴染みがなかったから string を
mutable にしたんだろう。

それと、「a == b ならば a.equal?(b)」という一意性と、
即値は一応別の概念であって、即値を採用したのは効率の
ために過ぎず、Fixnumなどの一意性は即値の副産物として
たまたま得られたものだ。