- Ruby 初心者スレッド Part 55
182 ：173[sage]：2014/07/31(木) 01:25:29.27 ID:h0+6R2oI - （>>178 の続き）
・メソッドのオーバーロードができない
Ruby => (Python や JavaScript と同様に)動的型付け言語である Ruby では、
引数のデータ型を実行時に判別(イントロスペクション)できるので、
メソッドのオーバロード(多重定義)は「必須ではない」と思います
・ファイルで名称空間が切られる
Ruby => Ruby ではモジュール宣言を使って名前空間が切られますから、
ファイルと名前空間との一致という「規則を強制する Python」とは異なり、
名前空間というプログラムの階層的な論理構造と、ファイル/ディレクトリという
プログラムの階層的な物理構造をプログラマが自由自在に表現できます
・for文にindexがない
Ruby => これも >>173 にある「割り算の結果」の項目と同様に、著者がC言語風の
indexを伴うfor文がある JavaScript の経験が長いので、不満に感じるのだと思われます
Ruby だと、index を伴う反復を以下のように書きます
list.each_with_index do |index, value|
puts "index:" + index.to_s
end
また Ruby 1.9 からは Enumerator オブジェクトとメソッド with_index が追加されたので、
関数型プログラミングのスタイルでコードを書くこともできるようになりました
puts list.each.with_index.map { |index, value| "index:" + index.to_s }
・配列/リストの長さはlenでとる
Ruby => 最初からオブジェクト指向言語として設計されているので、
配列の長さを求めるにはメソッド Array#length を使って list.length と書けます
これについては、すでに >>57 で解説しているので、ここでの詳細は省略します
（これで終わり、ここまでの連投カキコに対するレスは、明日になる）
|
- Ruby 初心者スレッド Part 55
184 ：173[sage]：2014/07/31(木) 21:19:14.83 ID:h0+6R2oI - >>174
間違っていると思うなら、具体的な説明を
感情的な反発だけでは、自ら敗北を認めたのと同じ
|
- Ruby 初心者スレッド Part 55
185 ：173[sage]：2014/07/31(木) 21:59:08.98 ID:h0+6R2oI - >>175
まず「JavaScriptに整数型は仕様上ない」という指摘は正しい
（ボケへの的確なツッコミが嬉しい）
ただし、それ以外の部分はメチャクチャだね
> 演算子を適用した結果の型がどうなるかは演算子の仕様の問題に過ぎず
> 型付けの強い弱いは関係ない
演算子(= 関数 or メソッド)の適用結果のデータ型が曖昧である事を許容する言語は、
曖昧なデータ型を禁止する言語と比較して「型付けが弱い」と呼ばれる
たとえばC言語では戻り値が「ある(オブジェクトへのポインタ) または NULL」という仕様の
関数定義を許すけど、ML や Haskell のような型付けに厳格な言語では型エラーとして
定義できず、代わりに直和型(ML ならOption型、Haskell ならばMaybe型)を使う
この対比のケースだと、C は ML や Haskell よりも「型付けが弱い」となる
つまり、データ型に関する仕様の曖昧さを認めるか否かという言語の設計方針は、
「型付けの強さ弱さ」を決める要因の一つである、ってこと
> 演算の自動リフトや型変換なんてC系の言語では普通にあることで
そういった「暗黙の型変換(implicit conversion)」あるいは「型強制(coercion)」と
呼ばれる仕掛けはプログラミングを楽にする効果がある一方で、
その多用は型検査の能力を阻害する悪影響がある
だから、それらを許可しない型付けに厳格な言語との対比として、
C言語系は「型付けが弱い」と呼ばれる
|
- Ruby 初心者スレッド Part 55
186 ：173[sage]：2014/07/31(木) 22:43:50.19 ID:h0+6R2oI - >>176
>演算による自動型変換が問題になりうるのは、次の両方を満たす場合だ。
発想の方向性は正しいと思うから、思考をもう一歩先に進めよう
言い換えると、「型が静的に決まらない」や「型によって演算子の意味が変わる」といった
要因は、どのような効果を導くのか？を考えてみよう、ってこと
その答えは、プログラマの(データ型に関する)誤り(=エラー)を見逃す可能性を増やす、
簡潔に言えば「型検査の能力を阻害する」ってこと
たとえば JavaScript のコード "A"+1 は、プログラマが "A1" が返る事を意図していたなら
正当で簡潔なコードだけど、もしもうっかり "1" をタイプミスしたとしたら
JavaScript処理系はミスの検出を見逃して最終的に予期しないバグとなる可能性がある
この「プログラマの表現力への制約を極力減らしつつ強力な型検査能力を提供する」ことは、
型体系(type system)の研究における重要な動機の一つになっている
> その観点では1.0/3と1/3で結果が同じになるPython3の仕様の方が
>「型付けが強い」と考えることもできる。
上で述べたように、型付けの強さ弱さとは、一般には型検査能力の程度を指す
（ただし「型検査」そのものが広い概念を指す曖昧な言葉であることに注意が必要）
このような「1.0/3と1/3で結果が同じになる」という、計算結果の同値性が
型付けの強さ弱さを決めるなどという珍説は、これまで見たことも聞いたことも無い
型付けの強さ弱さに関しては、Wikipedia に良くまとめてあるので、勉強されることを勧める
・Strong and weak typing - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Strong_and_weak_typing
|
- Ruby 初心者スレッド Part 55
188 ：173[sage]：2014/07/31(木) 23:18:05.47 ID:h0+6R2oI - >>180
おそらくコードの可読性というか視認性が要因だろね
メソッド名の頭に '_' または '__' が付いていれば、
「それは public じゃないから触っちゃ嫌よ」あるいは
「もし使いたいなら事前に仕様を十分に確認してね」
といったコードの意図が一目でわかる
また、１つクラス定義をできるだけ小さくしようとする
小クラス主義で設計することを考えているから、
スーパクラス-サブクラス間でメソッドを介して関連し、なおかつ
そのメソッドの外部からの利用を(protectedで)禁止するのが
望ましいというケースがほとんど無い(ちょっと思いつかない)
というのも理由かもしれない
最後に、実行前に違反を検出できないアクセス制御に
いったい何の価値があるの？という率直な疑問もあったりする
これはアクセス制御という発想が全く存在しない Smalltalk の影響を
受けているからではないかと思う
とはいえ、こうして指摘される迄、何も疑問に感じていなかった訳だから、
可視性(アクセス制御)の活用も今後は見直すかもしれない
|
- Ruby 初心者スレッド Part 55
190 ：173[sage]：2014/07/31(木) 23:54:45.04 ID:h0+6R2oI - >>187
>結果の型が曖昧であることをなるべく許容しないのであれば
>「動的言語なら」/演算子は常にfloatを返す仕様の方が曖昧さは少ないだろう。
もしも Python 3 に「演算子の左辺の型に関わらず結果値の型は一つに決まるべき」
という設計方針/哲学があり、それを演算子 / に適用して「左辺が整数と小数の
いずれでも計算値は小数を返すのが(曖昧さが無いから)正しい」としたのなら、
その主張の正当性を認めよう
>>> 1/2
0.5
>>> 1.0/2
0.5
では次にもう一つの演算子 // について試してみよう
>>> 1//2
0
>>> 1.0//2
0.0
あれ、おかしいな？左辺の型によって戻り値が整数になったり小数になったりしている
もしかすると、Python には一貫した設計方針/哲学なんて高尚なものは存在せず、
演算子の種類によってコロコロ方針を変える(大人の汚い)やりかたが正しいと考えているのかな？
|