Matzにっき

_ [Ruby] tech addict - ruby gotchas and caveats

Rubyの落とし穴。

1. strings aren't auto converted into numbers or strings
2. false and nil are the only valid false values, anything else is true
3. && and || are the high priority AND/OR constructs, and and or are low priority versions
4. Exceptions and raise vs catch
5. no class/module unloading
6. no native unicode (ruby < 2.0)
7. private never truely private
8. 1/2 != 0.5 unless require 'mathn' (this is the default in many languages anyway, sometimes integer math is your friend). With mathn 1/2 becomes a different type (Rational) than 0.5 (Float)
9. class variables and their inheritance semantics
10. singleton class modification for the class objects isn't good or really allowed
11. assignment methods always return the assigned value, not the return value of the assignment function
12. local variable scoping is tricky and can hide other variables and methods (this is slated for a change in ruby 2.0)
13. You might think that class_eval would provide access to the class's context and variables, apparently not so much.

実例を見ないとわからないものもあるが、まあ、おおむね妥当であろう(ただし、6は誤解。1,2,3,4,7,8,11,12は慣れの問題。9,10,13はもうちょっと考えてみよう)。

追記

コメントにもあるように5も誤解。クラス名である定数が削除され、 サブクラスが存在せず、インスタンスがすべて回収されれば、 クラスやモジュールもGCの対象になる。 ライブラリ全体をunloadする機能はないが、ある言語の方が珍しいと思う。

9は1.9では解決されている(クラス変数は継承しない)。

10はsingleton methodはクラス変数の場所を変更しない(囲んでいるclass文だけで決まる) ことを理解すれば問題なし。慣れの問題。

13はあまり使いやすくない仕様なので、将来の1.9では変更しよう。 手元ではもう直した。

どう変更したかと言うと、以下の通り

• クラス変数の格納場所はもっとも内側のclass文またはmodule文が定義しているクラス(またはモジュール) [これは以前から]
• 特異メソッド定義は「格納場所」を変えない [以前から]
• 特異クラスも「格納場所」の対象になる [新規]
• よって特異クラス定義は「格納場所」を変更する [新規]
• トップレベルにはそれを囲むclass文もmodule文もないから、警告が出る [以前から]
• トップレベルでのクラス変数の「格納場所」はObject [以前から]

これもeigenclass化への一歩かもしれない。

_ [言語] Guido van Rossum on the Python 3000 process

Python 3000について、抽象的な話が多くて、 具体的な実装などについて語る人はあんまりいないという話。

Pythonくらい大所帯だといろいろ大変なんだろうなあ。 Rubyでは抽象的な話をしたがる人もあまりいないから。 まあ、それは私がすき勝手できるということでもあるのだけれど。

• Python 3000は2007年前半リリース希望
• UnicodeとStringの統一(Bytesの新設)
• IOの再実装
• keys, items, values()のイテレータ化戻り値の変更

また、Python 3000の先、Python 4000の話を始めてくれて結構、とのこと。 Python 3000が具体的になりそうになって、新たな「遠くの目標(aka 燃料)」が必要になった とも言えるかもしれない。