«前の日(07-28) 最新 次の日(07-30)» 追記

Matzにっき


2003年07月29日

_ [OOP]オブジェクト指向は難しい

昨日、オブジェクト指向の部分でつまづいていますというツッコミをいただきました。 人によって「オブジェクト指向」のつまづき方はそれぞれだと思うので、 誰にでも分かるという説明は実は困難なのですが、最初のきっかけになる解説を試みようと思います。 これより先は書籍なりを参照してください。

Rubyで最小限覚えないといけないオブジェクト指向の基本概念は以下の通りだと思います。

  • 「値」はすべて「オブジェクト」と呼ぶ
  • 「オブジェクト」の「メソッド」を呼べる。「オブジェクト」は「メソッド」が呼ばれると自分に合わせた処理を行う。
  • 「オブジェクト」は「クラス」に所属する。
  • 「オブジェクト」が持つ「メソッド」は(原則的に)その所属する「クラス」で決まる。

ね、そんなに難しくないでしょ。

あと、ドキュメントを読むために「継承」を理解した方が良いかもしれません。

  • 「クラス」は親となるクラスである「スーパークラス」を持つ。
  • ある「クラス」に所属する「オブジェクト」が持つ「メソッド」は、そのクラスで定義されたものと、スーパークラスで定義されたものを(先祖までさかのぼって)合わせたものだ。

それからRubyにはMix-inがありますから、これも押さえておきましょう。

  • 「メソッド」などをまとめる単位として「モジュール」がある
  • 「クラス」は「モジュール」をincludeできる(これをMix-inと呼ぶ)
  • includeされた「モジュール」の「メソッド」は「スーパークラス」同様、「クラス」に受け継がれる

ですから、文字列のクラスである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

    という「オブジェクト指向」の嬉しさの違いです。

  • 機能がクラス単位で整理されるので理解しやすい。 つまり、Perlのリファレンスマニュアルのように数百の関数がフラットに並ぶのと比べると、 Rubyのリファレンスマニュアルのように文字列の機能はStringクラスに、 すべてのオブジェクトに共通の機能はObjectクラスに分類されている方が、 整理されていると感じられます。
  • 継承によって機能の拡張が行いやすい(時がある)。 つまり、既存のクラスとほとんど機能が同じだが微妙に違うクラスを作りたい時には、 既存のクラスを継承して、微妙に違う部分だけ追加したり、書き換えたりするだけで、 新しいクラスを作れるというもの。これを「差分プログラミング」と呼ぶ。

「差分プログラミング」はさほど重要ではないのですが、 オブジェクト指向を解説した書籍では必要以上に強調される傾向があります。

まあ、最初の一歩としてはこんなもんでしょうか。


2004年07月29日

_ [OSS]IronPython

.NET上のPython処理系IronPythonがとうとう公開された。 オレゴン州ポートランドで開催中のOSCON 2004にあわせての公開らしい。

で、さっそくソースを読んでみるが、大変読みにくい。 C#に慣れてないってのもあるけど、 C#のリフレクションとIronPythonのリフレクションとが渾然一体となっていて 区別が付けにくいのがつらいところだ。

どうやら、メソッドは生成したILのコードをdelegateとして保持しておいて、 それを直接呼び出しているらしい。だから、メソッド呼び出しは、

  • 呼び出すメソッドを検索してメソッドオブジェクトを取得
  • そのメソッドオブジェクトにcallを適用
  • メソッドオブジェクトのもつdelegateを呼び出し

という手順のようだ。確かに呼び出しにはリフレクションを使っていないが、 これで速いんだろうか。まあ、もともとのCPythonのセマンティクスも同じようなものなんで、 大丈夫なのかな。

そういえば、Jythonのソースは読んでないな(Java嫌い)。

_ [Ruby]Language Update 2004

LL Weekendが近づいているので、私の担当分Language Updateについてまとめようとするが、 今年(去年のLLから最近まで)は、言語仕様については進歩があんまりないことに気がついた。

一体、私はこの1年なにをしてたんだ(日記を書いてました)。

しかたがない、あと10日ほどの間にでっち上げるのはどうだろう。作者の強み。

  • 国際化(M17N)の1.9への取り込み

    どうせこの夏、論文に書くために、再実装+1.9へのマージを予定していたので、前倒しする、とか。

  • メソッドコンビネーション

    こっちは完全な新機能なので互換性の問題はない。が、効率の良い実装が大変なんだよねえ。 で、前田くんと議論したが...その結果は後で。

やっぱ無理があるかな。

_ [Ruby]メソッドコンビネーション

というわけで、メソッドコンビネーションだ。

メソッドコンビネーションは、メソッドの前と後ろにフックをかけることを許すものだ。 CLOSで提供されている機能で、 一種のアスペクト指向と呼んでもよいかも。 というか、AspectJのGregor Kiczalesは元々CLOSのデザイナーでもあるから、 メソッドコンビネーションなどから発展してアスペクト指向が生まれたと言うべきだろうな。

これの効率の良い実装は難しい。 現在のRubyの実装を大きく変えないですむと嬉しい、という条件をつけるとなおさらだ。

思いついたのは(だれでも思いつきそうだが)、CLOSのメソッドコンビネーションが

  • aroundメソッドをサブクラスからスーパークラスへ
  • beforeメソッドをサブクラスからスーパークラスへ
  • primaryメソッドをサブクラスからスーパークラスへ
  • afterメソッドをスーパークラスからサブクラスへ

という順序になっているのを、

  • サブクラスのメソッドをbefore, primary, afterの順
  • primaryでsuperが呼ばれたらスーパークラスのメソッドを
  • 以下、同じようにbefore, primary, afterの順

という順序の変更を考えてみた。 CLOSとは確かに違うが、別にまったく同じであることにこだわるほど、CLOSに忠誠を誓っているわけではない。

とはいえ、primaryメソッドでsuperが呼ばれなければ、beforeメソッドやafterメソッドが一切呼ばれない点は、 嬉しくないこともあるだろう。すぐに考えついたのは、たとえばロギング機能をこれで実装しようとしたら、 includeでは(beforeメソッドなどは明示的にsuperを使わないと呼ばれないので)役に立たないと言う点だ。

これはincludeが(仮想的な)スーパークラスを追加するものだからいけないわけだ。 たとえばSatherのようなcode inlcusionであれば、同じレベルなので問題はない。 とはいえ、いまさらincludeの意味を変えるわけにはいかないので、 新しいオペレーション(かmoduleのような別物)を導入する必要があるなあ....。

などと、次々と考えが発散するのであった。でも、上記のアイディアはけっこう魅力的だなあ。 問題は「新しいオペレーション」の名前だな。ほんとはincludeが最適だと思うけど、 これは変えられそうにないし、「埋め込み」とかを意味する単語だといいのかな。

前田くんは「expand」を提案していた。include, extend, expand...、 うーん、一度慣れてしまえば、それなりにいいかも。


2005年07月29日

_ [OSS] Matz日記分室: マイクロソフトのオープンソース論

CNETの記事に関連して、 分室に記事を書いた。

_ [知財] 「iPodなどを私的録音補償金制度の対象に」JASRACなどの7団体が声明

補償金分配のしくみを透明化してから出直してこいって感じ。

_ [OSS] 書籍『オープンソースを理解する』

オープンソースを理解する(秋本 芳伸/岡田 泰子)

先日の『オープンソースがビジネスになる理由』にひきつづいて、 今度は『オープンソースを理解する』を眺めてみた。

あんまり時間をとっていないので、良いとか悪いとか断言はできないけれど、 作者の人たち(秋本 芳伸さん, 岡田 泰子さん)は「フリーソフトウェア」の定義を間違えちゃったみたい。 フリーソフトウェアは「派生物もフリーソフトウェアでありつづける必要がある」と 明記されているので、どうやら彼らの定義ではフリーソフトウェアとは GPLを適用したソフトウェアのことらしい。

実際には「4つの自由」を保証する(ライセンスが適用された)ソフトウェアであれば フリーソフトウェアなので、たとえば派生物に対して強い権利を主張しない BSD系ライセンスのソフトウェアもフリーソフトウェアである。

あと、気がついたのは、ソフトウェア全般やオープンソースに詳しくない人にも 分かるようにそれなりにていねいに説明してあった。ソースコードとはなにか、とか。 初心者向けの文章が書けるということはそれだけで大したものではある。

次にチェックするなら可地さんの『図解 オープンソースのことがわかる本』かな。でも、田舎の本屋や図書館にはなかなか置いてないんだよな。


2006年07月29日

_ ミッフィー絵皿

ここしばらくローソンでチープな昼食が続いているのは、 ミッフィー絵皿を手に入れるためであった。

ミッフィー展以来、あの白ウサギを見るたびに末娘が 「みっしー、みっしー(まだミッフィーとは言えない)」と 嬉しそうにしているので、絵皿をプレゼントしたいと思ったからだ(親馬鹿)。

念願かなって、ようやっと30点。娘も喜んでいた。

よーし、パパ、二枚目にも挑戦しちゃうぞ。

当分、チープな食事が続きそうだ。 完全にローソンの思うつぼ。

_ [教会] キャンプ送迎

教会のキャンプで木曜日から出かけていた上の娘ふたりを、 吉備高原少年自然の家まで迎えに行く。

ここに行くのは久しぶり(5,6年ぶりのような)だが、 思ってたより遠いわ。今回は落合ICで降りて 下を通ったのだが、道を間違えるわ、 途中土砂崩れで工事中(片側交互通行)のところはあるわ、 めちゃめちゃわかりにくいところはあるわ、 本当に楽しかった。

でも、帰りは全行程高速で帰った。

_ Manning Contest Ruby for Rails

「Ruby for Rails」出版を記念したコンテスト。

「Ruby is to Rails as _________ is to ________.」の穴埋めをするというもの。

あなたなら何を埋める?*1

*1  〆切は7月末まででした。このエントリを書いたのが8月4日。だめじゃん。せめて結果を楽しみにしよう


2007年07月29日

_ [教会] イエス・キリストを信じる信仰

司会。

日曜学校は福音の第一原則のひとつ、 イエス・キリストを信じる信仰について。 あるいは、信仰という言葉が局面ごとに持つさまざまな側面について。 っていうか、聖書は技術書じゃないんで、 同じ単語が文脈ごとに違う意味を持ったり、 あるいは一つの概念の違う側面が強調されてたりして、 それも理解を妨げる要因のひとつだったりする。

まあ、公称数千年かけて書かれた書物だから。

_ 選挙

参院選挙。 私と妻は、期日前投票をすませておいたのだが、 どうも予想外の動きになりそうだ。

しかし、郵政民営化以外の点で自民党と政策的違いはほとんどなさそうな 国民新党の候補を応援してしまう民主党のポリシーはよくわからない。

将来、所属政党が自民党と合流するようなことになれば(郵政問題で妥協が行われれば可能性は十分にある)、 結果的に民主党と対立することになると思うんだけど。

敵の敵は味方、ということか。


«前の日(07-28) 最新 次の日(07-30)» 追記