- Rubyについて（アンチ専用） Part005
239 ：デフォルトの名無しさん[sage]：2020/10/18(日) 00:06:56.33 ID:4X85KByZ - >>235
>あとfor inをプロトタイプ汚染されたオブジェクトに対して回すと恐ろしいことが起きるから基本的に非推奨だよ
あえて触れなかったのですが、こう書くべきでしたね
for (x in xs) {
if (xs.hasOwnProperty(x)) {
x に対する処理
}
}
以下より引用：JavaScript: The Good Parts - 良いパーツによるベストプラクティス, C.10 for in 文, p140
>>236
>細かいところでいいかげんなところがちょくちょくある
同感ですね、自分もちょくちょくあります
そういった事柄はこちらで遠慮せずに発言されてはいかがでしょうか？
| - Rubyについて（アンチ専用） Part005
246 ：デフォルトの名無しさん[sage]：2020/10/18(日) 00:32:03.16 ID:4X85KByZ - >>233
自分はすっかり関数型プログラミングに慣れてしまったので、近頃だと for/while 文を
使うのは、古い Pascal や Perl のコードを Ruby へ写経(移植？)する時くらいですかね
ちなみに Ruby のブロック構文ですが、副作用がなければ波カッコ { … } で、
副作用(破壊的代入やI/O処理)があれば do … end と使い分けています
以下は定石(パターン化した)コードの雛形(スケルトン)です
result = xs.select { |x|
…
}.map { |x|
…
}.inject( … ) { |acc, x|
…
}
xs.select { |x|
…
}.map { |x|
…
}.inject( … ) { |acc, x|
…
}.each do |x|
… # 副作用(破壊的代入やI/O処理)を含む処理
end
具体的なコード例はこちらへ：https://ideone.com/PKMUhx
また、関数型プログラミングに興味がある方は以下をお読みください
・Rubyによる関数型プログラミング
http://xtmlab.com/misc/FPwithRuby.html
| - Rubyについて（アンチ専用） Part005
261 ：デフォルトの名無しさん[sage]：2020/10/18(日) 02:27:50.97 ID:4X85KByZ - >>240
>・型安全でない
型付けに関しては、話が長くなるからまた後で
>・前後の文脈を見ないとその部分単体ではローカル変数とメソッド呼び出しの見分けがつかない … (後略)
これは同意ですね、だから自分はメソッド呼び出しであれば self.hoge みたいに self を省略せずに書きます
>・reduce/inject、map/collectのように同じことするメソッドの単なる別名と、
Lisp 文化と Smalltalk 文化の融合ですが、そもそも Ruby は最初から手続き型/関数型/オブジェクト志向を融合した
マルチパラダイム言語として設計されていますし、コミュニティも多文化共存共栄(多神教？)みたいな空気がありますね
他の言語、たとえば手続き型原理主義(一神教？)で「聖典こそ真実であり、否定するものは異教徒」みたいな信者からすれば
違和感があるのかもしれませんね
>Array#delete_if/Array#reject!のようにほとんど同じなくせして削除失敗時だけ挙動が異なるみたいな … (後略)
関数型プログラミンングだと mutable な操作は使わないのでよう分からんですが、一度に全てを理解しようとせず、
必要になった時に必要なメソッドを使うよう思考を単純化したほうがよろしいのではないかと
>・Procオブジェクト（手続きオブジェクト）を作る方法が多すぎ。しかも作り方で挙動が異なる。 … (後略)
これも同意、自分は基本がブロック構文、もし稀に明示的なProcオブジェクト(いわゆるクロージャ)が必要になった時には
組み込み関数の lambda を使うくらいですね
前段でもお話したように、他の「作る方法」は(今のところ)必要がないので気になりません
>・簡単に「見せかける」ために省略記法を行き当たりばったりで導入しまくった副作用で、
>直感的な記述が逆にエラーとなることが多い（例： p {foo: 1, bar: 2}はエラーｗブロックとして解釈されるため）
波カッコを使うブロック構文とハッシュ構文を誤読する問題は、少なくとも自分が Ruby を触り始めた 1.6 の時代から
存在しますから、「行き当たりばったりで導入」した例としては不適切です
「直感的な記述が逆にエラーとなることが “多い”」のであれば、別の例を挙げるべきでしょう
|
|