昨日、オブジェクト指向の部分でつまづいていますというツッコミをいただきました。 人によって「オブジェクト指向」のつまづき方はそれぞれだと思うので、 誰にでも分かるという説明は実は困難なのですが、最初のきっかけになる解説を試みようと思います。 これより先は書籍なりを参照してください。
Rubyで最小限覚えないといけないオブジェクト指向の基本概念は以下の通りだと思います。
ね、そんなに難しくないでしょ。
あと、ドキュメントを読むために「継承」を理解した方が良いかもしれません。
それからRubyにはMix-inがありますから、これも押さえておきましょう。
ですから、文字列のクラスであるStringクラスには、長さを求めるsizeメソッドなどが定義されており、 スーパークラスであるObjectクラスから引き継いだobject_idメソッドなども持ちます。
さて、ではオブジェクト指向のメリットはなにか、ということですが、大きく分けると
オブジェクトが自分に合わせた処理を選ぶので、プログラマが選択する必要がない。つまり、 自分で値と処理の適切な組み合わせを選ぶ
str = "abc" string_size(str) #=>3 ary = [1, 2, 3, 4] array_size(ary) #=>4 string_size(ary) #=> error!!
という「非オブジェクト指向」と、言語が勝手に選択してくれる
str = "abc" str.size #=>3 ary = [1, 2, 3, 4] ary.size #=>4
という「オブジェクト指向」の嬉しさの違いです。
「差分プログラミング」はさほど重要ではないのですが、 オブジェクト指向を解説した書籍では必要以上に強調される傾向があります。
まあ、最初の一歩としてはこんなもんでしょうか。
.NET上のPython処理系IronPythonがとうとう公開された。 オレゴン州ポートランドで開催中のOSCON 2004にあわせての公開らしい。
で、さっそくソースを読んでみるが、大変読みにくい。 C#に慣れてないってのもあるけど、 C#のリフレクションとIronPythonのリフレクションとが渾然一体となっていて 区別が付けにくいのがつらいところだ。
どうやら、メソッドは生成したILのコードをdelegateとして保持しておいて、 それを直接呼び出しているらしい。だから、メソッド呼び出しは、
という手順のようだ。確かに呼び出しにはリフレクションを使っていないが、 これで速いんだろうか。まあ、もともとのCPythonのセマンティクスも同じようなものなんで、 大丈夫なのかな。
そういえば、Jythonのソースは読んでないな(Java嫌い)。
LL Weekendが近づいているので、私の担当分Language Updateについてまとめようとするが、 今年(去年のLLから最近まで)は、言語仕様については進歩があんまりないことに気がついた。
一体、私はこの１年なにをしてたんだ(日記を書いてました)。
しかたがない、あと10日ほどの間にでっち上げるのはどうだろう。作者の強み。
国際化(M17N)の1.9への取り込み
どうせこの夏、論文に書くために、再実装＋1.9へのマージを予定していたので、前倒しする、とか。
メソッドコンビネーション
こっちは完全な新機能なので互換性の問題はない。が、効率の良い実装が大変なんだよねえ。 で、前田くんと議論したが...その結果は後で。
やっぱ無理があるかな。
というわけで、メソッドコンビネーションだ。
メソッドコンビネーションは、メソッドの前と後ろにフックをかけることを許すものだ。 CLOSで提供されている機能で、 一種のアスペクト指向と呼んでもよいかも。 というか、AspectJのGregor Kiczalesは元々CLOSのデザイナーでもあるから、 メソッドコンビネーションなどから発展してアスペクト指向が生まれたと言うべきだろうな。
これの効率の良い実装は難しい。 現在のRubyの実装を大きく変えないですむと嬉しい、という条件をつけるとなおさらだ。
思いついたのは(だれでも思いつきそうだが)、CLOSのメソッドコンビネーションが
という順序になっているのを、
という順序の変更を考えてみた。 CLOSとは確かに違うが、別にまったく同じであることにこだわるほど、CLOSに忠誠を誓っているわけではない。
とはいえ、primaryメソッドでsuperが呼ばれなければ、beforeメソッドやafterメソッドが一切呼ばれない点は、 嬉しくないこともあるだろう。すぐに考えついたのは、たとえばロギング機能をこれで実装しようとしたら、 includeでは(beforeメソッドなどは明示的にsuperを使わないと呼ばれないので)役に立たないと言う点だ。
これはincludeが(仮想的な)スーパークラスを追加するものだからいけないわけだ。 たとえばSatherのようなcode inlcusionであれば、同じレベルなので問題はない。 とはいえ、いまさらincludeの意味を変えるわけにはいかないので、 新しいオペレーション(かmoduleのような別物)を導入する必要があるなあ....。
などと、次々と考えが発散するのであった。でも、上記のアイディアはけっこう魅力的だなあ。 問題は「新しいオペレーション」の名前だな。ほんとはincludeが最適だと思うけど、 これは変えられそうにないし、「埋め込み」とかを意味する単語だといいのかな。
前田くんは「expand」を提案していた。include, extend, expand...、 うーん、一度慣れてしまえば、それなりにいいかも。
CNETの記事に関連して、 分室に記事を書いた。
補償金分配のしくみを透明化してから出直してこいって感じ。
488648719X
先日の『オープンソースがビジネスになる理由』にひきつづいて、 今度は『488648719X』を眺めてみた。
あんまり時間をとっていないので、良いとか悪いとか断言はできないけれど、 作者の人たち(秋本 芳伸さん, 岡田 泰子さん)は「フリーソフトウェア」の定義を間違えちゃったみたい。 フリーソフトウェアは「派生物もフリーソフトウェアでありつづける必要がある」と 明記されているので、どうやら彼らの定義ではフリーソフトウェアとは GPLを適用したソフトウェアのことらしい。
実際には「4つの自由」を保証する(ライセンスが適用された)ソフトウェアであれば フリーソフトウェアなので、たとえば派生物に対して強い権利を主張しない BSD系ライセンスのソフトウェアもフリーソフトウェアである。
あと、気がついたのは、ソフトウェア全般やオープンソースに詳しくない人にも 分かるようにそれなりにていねいに説明してあった。ソースコードとはなにか、とか。 初心者向けの文章が書けるということはそれだけで大したものではある。
次にチェックするなら可地さんの『4534039050』かな。でも、田舎の本屋や図書館にはなかなか置いてないんだよな。
ここしばらくローソンでチープな昼食が続いているのは、 ミッフィー絵皿を手に入れるためであった。
ミッフィー展以来、あの白ウサギを見るたびに末娘が 「みっしー、みっしー(まだミッフィーとは言えない)」と 嬉しそうにしているので、絵皿をプレゼントしたいと思ったからだ(親馬鹿)。
念願かなって、ようやっと30点。娘も喜んでいた。
よーし、パパ、二枚目にも挑戦しちゃうぞ。
当分、チープな食事が続きそうだ。 完全にローソンの思うつぼ。
教会のキャンプで木曜日から出かけていた上の娘ふたりを、 吉備高原少年自然の家まで迎えに行く。
ここに行くのは久しぶり(5,6年ぶりのような)だが、 思ってたより遠いわ。今回は落合ICで降りて 下を通ったのだが、道を間違えるわ、 途中土砂崩れで工事中(片側交互通行)のところはあるわ、 めちゃめちゃわかりにくいところはあるわ、 本当に楽しかった。
でも、帰りは全行程高速で帰った。
司会。
日曜学校は福音の第一原則のひとつ、 イエス・キリストを信じる信仰について。 あるいは、信仰という言葉が局面ごとに持つさまざまな側面について。 っていうか、聖書は技術書じゃないんで、 同じ単語が文脈ごとに違う意味を持ったり、 あるいは一つの概念の違う側面が強調されてたりして、 それも理解を妨げる要因のひとつだったりする。
まあ、公称数千年かけて書かれた書物だから。
参院選挙。 私と妻は、期日前投票をすませておいたのだが、 どうも予想外の動きになりそうだ。
しかし、郵政民営化以外の点で自民党と政策的違いはほとんどなさそうな 国民新党の候補を応援してしまう民主党のポリシーはよくわからない。
将来、所属政党が自民党と合流するようなことになれば(郵政問題で妥協が行われれば可能性は十分にある)、 結果的に民主党と対立することになると思うんだけど。
敵の敵は味方、ということか。