Mix-inとか、うっかり防止とか

「あとそういえばMix-inという用語がちゃんとあった」 http://d.hatena.ne.jp/w_o/20081205#p3

これの問題は、「うっかりメソッド追加し忘れたら死亡」という点だろうか。最近ちょっとうっかりすることが多いというか、死亡しすぎな気がする。

あと、書かれそうなので書いておくと、↑のは、dictをまわして追加すればいいとか、そういう話はあまり期待してないです。

じゃあ、どういう話を期待してるかというと、そういう「うっかりしたら死亡」することに対してセーフィティーが無いのって、どうなんだろうなぁ。とかそういう。

ルビーやパールとかはそういうのもアリという空気があるけど、PYてょんの人達はそういうのはアリという空気は無いので、どう考えてるのかは気になる。

「死亡」の定義が曖昧だな。 syntax error じゃなくて実行時エラーになると死亡?それともバグに気づかずにリリースしてしまうのが死亡?前者なら最初から静的型付け言語使うべき。後者だという前提で話を続ける。

まず、「うっかりメソッド追加し忘れたら死亡」ということは無い。

self.foo = self._foo.foo したとき、 self.foo は bound method なので、 self.bar = self._foo.bar し忘れていて、 foo() が内部で bar() を呼び出していても、 self._foo が bar の第一引数として渡される。忘れること自体を問題とするなら、一度でも実行したら簡単かつデバッグの必要すらないほど直接的に判る問題だから、死亡になり得ない。

ただし、 Mix-in を目的とするならやはり多重継承を使うべきだ。そして、親クラスのコンストラクタ呼び忘れは、その親クラスが「__init__()忘れても一見普通に動くけど特定条件でエラー」だったりすると死亡に繋がるかもしれない。

「ルビーやパールとかはそういうのもアリという空気があるけど、PYてょんの人達はそういうのはアリという空気は無いので」というのは違うと思う。 Pythonの場合、「シンプルな仕組み」、「暗黙よりも明示」、によってプログラマに間違えにくくさせているけれども、基本的にはプログラマを信用している言語だと思う。たとえば、「子供じゃないんだから」といって強制的な public/private によるアクセス制御を採用せず、アンダースコアで「見た目でわかる」だけで済ますとかも、プログラマを信頼しているからこその設計。

このブログに乗せているコードは引用を除き CC0 1.0 で提供します。