Created
February 28, 2014 02:16
-
-
Save takkanm/9263886 to your computer and use it in GitHub Desktop.
and_return に関する考察
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
koic Feb 27 19:10 | |
and_return とブロックのいずれが良いか :sushi: と話しております | |
koic Feb 27 19:18 | |
:sushi: 逃げました | |
moro 10:36 | |
95%くらいはand_return じゃなくてブロックがいいと思います | |
moro 10:36 | |
5%くらいのレアケースは是々非々で | |
koic 10:38 | |
@moro ブロックの方がいい意図はありますか? | |
koic 10:38 | |
直感的にブロックの方がいい気はしているのですが、説明ができない | |
akiinyo 10:43 | |
「見た目がスッキリするからー」は説得力低かった :see_no_evil: > ブロックの話 | |
koic 10:43 | |
@akiinyo うん。見た目がすっきりかなー。 | |
moro 10:45 | |
え、見た目がスッキリのなにがだめなんだろ。 | |
moro 10:46 | |
and_return のメリットって何かあるんです? | |
koic 10:46 | |
見た目がすっきりでいいと思います。それ以上の意図があったりするのか気になったので。 | |
moro 10:47 | |
英語っぽく | |
koic 10:47 | |
あー | |
moro 10:47 | |
しようとするために書いてある情報のS/N比を下げなくていいよね | |
moro 10:47 | |
っていう。 | |
takkanm 10:47 | |
前に moro からうけた、引数にとる stub や mock したいメソッド名の中身がブロックにあると Ruby っぽいが説得力あるかなぁ | |
moro 10:47 | |
英語モドキを書いているわけではなく、プログラムを書いているのです。 | |
koic 10:48 | |
nrhd! | |
takkanm 10:48 | |
「スッキリする」だけだとまだ微妙に納得できない | |
takkanm 10:48 | |
「define_method と一緒なんです」が説明しやすいか | |
moro 10:48 | |
納得できない勢には「and_returnの良さ」を語って欲しいけど、なんかあるの? | |
moro 10:49 | |
and_とかいらなくね? | |
koic 10:49 | |
www | |
takkanm 10:49 | |
and_return の方が明確に値返すように見えるから | |
koic 10:49 | |
あー | |
moro 10:50 | |
and_がいらない。 | |
kenchan 10:50 | |
即値を返すならand_returnがいいかなーとはと思っていました。(andがいらないは同意) | |
takkanm 10:50 | |
メソッド名については return でもいいとはおもいます | |
moro 10:51 | |
うーん「ブロックの評価値が返る」で十分にわかりやすいと思うのだけど | |
koic 10:52 | |
and_ で S/N 比が下がっているまで理解した | |
takkanm 10:53 | |
そういえば ブロックとるときって、with ってどうつけるんでしたっけ ? (あんまり使ってなかったからわかってない | |
takkanm 10:53 | |
s/ブロックとる/ブロックで値を返す/ | |
moro 10:55 | |
ふつうに使えるし、ブロック引数になるのでそっちで見ても良いです。 | |
moro 10:56 | |
ブロック引数として渡ってくるので | |
kenchan 10:56 | |
and_returnするときは、文字列のシングルクォートと一緒で、返す中身はあんまりみなくていいよー宣言をしていたのかも | |
kenchan 10:56 | |
と思いました。引数をちゃんと使うときは中をみてほしいのでブロック | |
takkanm 10:56 | |
should_recive(:foo) { 1 }.with(0) みたな ? これは順が逆転してる気がして気持ちわるいような | |
moro 10:57 | |
expect(o).to receive(:foo).with(:bar) { true } | |
expect(o).to receive(:foo).with(:bar).and_return true | |
moro 10:57 | |
@takkanm 最後に書けるよ | |
moro 10:57 | |
上のほうが好きだなあ。即値が超自明じゃね? | |
moro 10:58 | |
関係ないけど、expect syntaxはmock/stubに使うのはよいですね。そっちは明らかに優れていると思う | |
moro 10:59 | |
it { is_expected_to }はどうかと思いますが | |
moro 10:59 | |
it_is_expected_to { } のほうがまだ | |
moro 10:59 | |
どちらも要らない派 | |
takkanm 10:59 | |
それは、expect(obj).to との対称性をとるためのものですからねぇ | |
takkanm 11:00 | |
なんでワンライナーだけ should なん ? っていう問いへの回答 | |
moro 11:00 | |
まあRSpec::Mocks::Double#must とか RSpec::Mocks::Double#may とかでもいいけどね。 | |
moro 11:01 | |
double(:mock).must receive(:bar) | |
double(:stub).may receive(:piyo) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment