なんとpreview7まで出てしまった。
などなどが忙しく、日記を書いてる暇がありません。
オブジェクト指向の件の続きとか、VAIO U101の話とか、書きたい話はたくさんあるのですが。 一段落して、気持ちに余裕ができたら、ね。
月曜日リリースの約束を守ろうと思っているのだが、今になってもバグレポートが来る。
もちろんリリース前にバグが減るのはありがたいのだが、これがリリース後にもどんどん見つかる 予兆ではないかと思えてしかたがない。だいたいリリースにはイヤな思い出がたくさんあるし。
不安だ。
なんとなく北斗七星の隣に小さく輝く星を見たような気がする。
いや、それは違う、という話はまた今度。
米子の実家で花火を見た。妹夫婦、弟夫婦も来ていたのだが、妹のダンナは具合が悪くなってしまったので (働き過ぎか)、途中で帰ることに。
子供たちはしっかり遊んですっかりくたびれて帰った。楽しんだようだ。
えー、 オープンソース関係者はひらがなの名前が多いという指摘ですが、実際のところどうなんでしょう。Rubyコミュニティでは明らかに目立ちますが。 私とか「わたなべひろふみ」さんとか「やまだあきら」さんとか。
私の場合は単純な理由で、「松本」なんてありふれた名前を差別化したいというものです。 それとひらがな表記が気に入っているというのもあります。
最初のきっかけは小学生のときです。授業に使う算盤を注文することになって、 裏に名前を入れてもらうので注文書に名前を書くことになっていました。 当時から少々ひねくれていた私は、
書いたのです(バカ)。
数週間後、届けられた算盤にはひらがなの名前が刻まれていました。
たぶん、小学校3年か4年ころのことだと思うのですが、その時改めてひらがなの自分の名前を見た私は、 「この文字は丸みを帯びて美しい」と感じました。私の名前の漢字は直線ばかりですが、 ひらがなのほうはどれをとっても丸いものばかりです。
それ以降、私はひらがなの名前を多用するようになりました。
というわけで、 私がひらがなの名前を使うのは、冗談ではなく小学生のころからだというお話でした。
日経ITProの記者の眼でRubyが扱われていた。
結構、好意的に扱ってあるではないか。これを書いた矢崎さんは今月の日経ソフトウェアの9月号の特集で、PerlとRubyを扱ってくださった方だ。
最初は私に原稿の依頼があったのだが、ちょっと手に余ったのでお断りして、 代わりに、吉田さん(moriqさん)にお願いした。 『4274065154』の著者のmoriqさんなら適任だし、 任せても安心だと思ったからだ。 さいわい、快く引き受けてくださった。
矢崎記者がRubyに対して好意を持ってくださったのはmoriqさんのおかげが大きいと思う。
いや、Rubyが優れているのもあるんだけどね(不遜)。
満を持してリリースしたはずの1.8.0にすでにバグがいくつも見つかっている。 リリースエンジニアリングって難しい。
また、次の点も指摘されている(重要ではないが)。
これをどうしたものか、1.8.1を出すのは早すぎると思うし、 1.8.0メンテナンスリリースとか用意しようかなあ。
Linuxビボ〜ろくより。
greenteaさんが 「GUIでは継承を使わない」って書いたことが発端です。
で、その中でgreenteaさんは
継承を多用することについての戒めとしては「オブジェクト指向スクリプト言 語 Ruby」でも「継承は最後の武器だ」と述べられています。
と述べておられます。
確かに私は『4756132545』の中で、 「継承は最後の武器だ」と書きましたが(p.219, p.562)、別に継承を避けろというつもりはないのです。
例によって私の表現が安易だったのですが、この機会に補足説明させてください。
まず、元ネタから説明しましょう。この言葉の元となった「拳銃は最後の武器だ」というセリフは、 『忍者部隊月光』の劇中で多用されるのですが、 実際には拳銃はばんばん使われてます。 ですから、意図としては「使うな」ではなく、「使う前に考えろ」です。
さて、技術的な点から考えると、greenteaさんも引用しているように 「継承はカプセル化の概念を破壊する」 あるいは「クラス継承よりもオブジェクトコンポジションを多用すること」 とはよく言われます。
しかし、私は同意しません。
(ちゃんと考えた後でも)継承を使いたくなるケースでは、 オブジェクトコンポジションの方が継承よりも優れていることはまれだからです。 むしろ、明示的な委譲の定義が繁雑で、「こんなこと自分でしなくちゃいけないのは変だ」と感じます。 そんなことを言語に押しつけて自動で片付けるための仕組みが、 オブジェクト指向言語の継承機能であったはずです。
「継承はカプセル化の概念を破壊する」件については、また別にもう少し考えなければなりません。 なぜ継承がカプセル化の概念を破壊するかといえば、 サブクラスはインスタンスの構造に直接触ることができるからです。
インスタンス変数を直接参照すれば、スーパークラスの実装に強く依存してしまいますし、 インスタンス変数を直接更新すれば、インスタンスの不整合な状態を作り出すことができます。 確かにこれはカプセル化の原則に対立します。
しかし、スーパークラスで定義されたインスタンス変数に直接触ることができることは、 オブジェクト指向言語にとって必須ではありません。たとえばC++はprivateなメンバには サブクラスからもアクセスすることができません。そしてさいわいなことにprivateがデフォルトです。 これが私の考えるC++の唯一優れた点なのですが。
Rebecca Wirfs-Brock女史は1988年のOOPSLAの論文でResponsibility Driven Designについて述べています。
その論文の中で、クラスの利用者は
の三種類があり、それぞれに見せるべき視点が異なると述べています。C++のpublic, private, protectedは まさにこの三種類に対応しているのです。余談ですが、去年のOOPSLAで会った時にWirfs-Brock女史のサインをもらってきました。彼女のファンなんです(ミーハー)。
結局問題なのはRubyのような言語がスーパークラスのインスタンス変数に簡単に触れてしまうという 「言語上の欠陥」なのであって継承そのものの問題ではないのですよね。 Rubyの次の世代の言語はぜひ「インスタンス変数はクラスローカル」が常識になってもらいたいものです。 事実、Perl6ではそうなるってDamian Conwayが言ってました。
というわけで、私の言葉を引いて継承を使わないほうがよいというのは、 私の本意とは違うんだ、ということです。
最後にどんな継承がまずいのか、あるいは不要なのか、について述べておきます。
私個人が継承を用いるかどうかについての唯一絶対のルールは「is-aの関係にあるか」です。 この関係が成立しない時に継承を使うのは純粋に間違いです。
では、この話の出発点に戻って「GUIに継承を用いるべきか」ですが、 ケースバイケースとしか言いようがありません。 ただ、
場合には遠慮無く使った方が良いと思うのです。ちゃんと考えた後でね。
なんか以前にもどこかで書いたような気がするけど、私がなんの修飾もなく 「オブジェクト指向」と表現する時には、ほとんど「オブジェクト指向という考え方」を意味するつもりでいる。
そして、その最低限の条件は「アイデンティティがある」ことである。 アイデンティティとはある「オブジェクト」と別の「オブジェクト」が、 同じかそうでないか判定できる、という意味だ。
たったそれだけのことならば別にオブジェクト指向言語を使う必要はない。 Cのstdioだって、UNIXのシステムコールだってオブジェクト指向だ。 どんな言語、どんな環境でプログラムするかではなく、 プログラムする対象をどう捉えるかという考え方が重要なのだ。
でも、これだけではあんまり嬉しくない。
そこで、あえてもう一つの条件を付け加えるなら、 「あるアイデンティティがある存在(＝オブジェクト)は自分に対して適応可能な処理を知っている」こと、 つまり「動的結合」とか「ポリモルフィズム」と呼ばれる概念を挙げたい。
この二つがあれば「オブジェクト指向(という考え方)」は十分である。
よく、オブジェクト指向の三要素として
のみっつが挙げられるが、「継承」と「カプセル化」はあくまでも「あると便利なもの」であって、 必須ではない。そのことは
が十分オブジェクト指向言語であること、 つまりオブジェクト指向という考え方に従ったプログラミングを十分支援していることからも分かる。
でもって、そういう「ファンダメンタルなオブジェクト指向」に付け加えて、
いろいろなレベルがあって、人によってどのレベルで「オブジェクト指向」 という単語を使っているかが異なっているので、 過去長らく発生した不毛な論争の原因になっていたのだと思う。
それよりなにより、誰もが自分の使っているオブジェクト指向言語から学んだ「オブジェクト指向」に こだわりすぎていて、一般化・抽象化が行われなかったことが不幸だと思う。
いや、私もけっして人のことは言えないのだが、私自身は
という経緯があるので、比較的オブジェクト指向という考え方を一般化しやすい立場にあるのではないかと思う。
渋谷のアジアンキッチンで夜8時から開催されました。 約30人のRubyユーザに取り囲まれてぼこぼこにされました。えーん(嘘)。
いや、それはそれとして、 昨日の夕食はタイ料理、今日の昼食はカレー(ナン付き)、 夕食はアジアンキッチンとアジアンな食事になったものです。 「アジア人だからいいのだ」といったのは、なかださんだったっけ。
手元の広辞苑によれば
アイデンティティ
人格における同一性。ある人の一貫性が成り立ち、 それが時間的・空間的に他者や共同体にも認められていること。 自己同一性。同一性。主体性。
なのだそうだ。たとえば、私の同姓同名の「まつもとゆきひろ」という人がいるとしても (本当にいる)、その人と私は違う人間であり、区別もできる。 これは人間にはアイデンティティがあるからだ。
では、アイデンティティがないとはどういうことか。 ある二つの「値」があって、それがまったく同一のものか、 それともたまたま値が共通なのか知る方法がない時、アイデンティティが存在しない。
たとえば、PerlやBASICの文字列にはアイデンティティがない。 文字列を変数に代入する時、内部的にコピーが起きるかもしれないし、 そうでないかもしれない。あるいは代入が発生した時点では(内部的には)同一でも、 後で知らないうちにコピーに変わってしまうかもしれない。
アイデンティティがないということは、 「値」つまり「状態」にしか興味がないということだ。状態は(通常は)オブジェクトではない。 オブジェクトに関心がないということは、それはすなわちオブジェクト指向ではない。 よって、オブジェクト指向の本質としてアイデンティティが必要である、ということになる。
上記の理屈はとりあえず置いておくとして、アイデンティティは本当に必要かという点について、考えてみよう。実は以前のPHPの話のとき、 harukiさんの「リファレンスが無くてもオブジェクト指向できるのでは？」というツッコミに対して書こうと思ってた内容だ。
私の理解が正しければ、harukiさんの論理は「PHP4では代入によってコピーが発生する」が、 PHPにはオブジェクト指向機能がある、よってアイデンティティがなくてもオブジェクト指向ができる、 というものだったと思う。
しかし、PHPのオブジェクト指向機能はリファレンスというアイデンティティを利用しているので、 この論理は成立しないと思う。もしPHPにリファレンスがなければ オブジェクト指向プログラミングは不可能だろう。
私のもっともよく知っているアイデンティティのない言語はPerl4である。 バージョン4より前のPerlの「値」にはアイデンティティがない。 スカラー(数と文字列)も配列もハッシュもその内容でしか判定することはできない。 この言語でオブジェクト指向を行うことはほぼ不可能だ。 唯一アイデンティティを要求しそうなファイルハンドルは「グロブ」という シンボルテーブルのエントリをアイデンティティとして導入しなければ実現できなかった。
もうひとつのアイデンティティのない言語の例としてはTclがある。Tclには文字列というデータ型しかなく、 この文字列にはアイデンティティはない。 しかし、「オブジェクトパス」(.frame.buttonのようなの)や、番号のようなID(まさにアイデンティティの略だ)を 導入してオブジェクトを表現している
やはり、オブジェクト指向プログラミングにはアイデンティティが必要であると考えられるのではないだろうか。
とはいえ、つらつらと考えるに、 リファレンスのまったくない言語でオブジェクト指向プログラミングができる可能性はゼロではないかもしれない。
というのは、オブジェクトを更新するような副作用がまったくなければ、 アイデンティティはさほど重要にならないからだ。 Rubyの実装においてFixnumは厳密にはオブジェクトではなく単なる「値」なのに、 オブジェクトとして振る舞うことができるのもその例だ。
しかし、副作用の全くないオブジェクト指向プログラミングというのは、 なかなか考えにくい。はたして実用的に可能なのだろうか。 もし可能なら関数型言語に完全に整合したオブジェクト指向機能が実現できそうだが。 O'Camlには副作用があるしなあ。
台風で天気が悪いが、150人以上の人が集まった。
プレゼンもなんとか完了。しかし、うちのマシン、最近プロジェクタに出力できなくなってるんですけど、 壊れつつあるんでしょうか。
私にとってはあんまり新しいネタはなかったんだけど(当たり前？)、 聴衆の皆さんにとってはどうだったんでしょう
ということで、LL Saturdayが終了したらとるものもとりあえず、 空港に向かったのだが、飛行機の到着が遅れているとさんざん待たされる。 しかし、さんざん待たされた後に天候不良のため欠航だと。しょっく。
最終便なので、他に変える手段はなく、明日の飛行機はことごとく満席だし、 どうしたもんだが。
というわけで、また東京泊になってしまったのだった。 明日早朝から新幹線で松江に向かいます。疲れるんだよなあ。
結構バグが見つかっている。やっぱり1.8.1だろうか。まだ決めかねている。
リンク集ができていた。 なかなかいろいろな感想があって楽しい。
やはり自分がどう見られているかには関心があるのだが、
うーん、やっぱ子供っぽいか。娘にも「大人げない」とか言われるものなあ。
私自身のLLの感想はと言うと、
P3は
とちょっと辛かった。コードのプリントが全員の手元にあったら、すごい役に立った思うんだが。 まあ、そのうち資料公開されるだろう。
今日から休みをとって(というか、会社に行かない宣言をして)、 妻の実家である山口に移動。
私の実家も、今住んでるアパートも、妻の実家もみんな国道9号線から少し入ったところにある。 もっともそれぞれの距離は相当離れているのだが。
というわけで、傷がついたままの車に家族を詰め込んで山口まで移動。 はしゃぐ子供たちがうるさい。
寄り道をしたので実に7時間近くかかって山口につく。3分の1は妻が運転したのだが、 私の方がすっかり疲れてしまって、ついたそうそう居眠りをしてしまう。 いや、ゆうべ3時までIA64でのデバッグをしていたのがいけないんだけど。
で、途中での寄り道と言うのが、 「浜田市世界こども美術館」で 開催中の「トリック×トリック」展である。 これは江戸の遊び絵とM.C.エッシャーの作品展示である(8月31日まで)。
私は元々エッシャーの絵が好きなので(「上昇と下降」とか)、これが目当てだったのだが、 江戸の遊び絵もそれなりに面白かった。
印象深かったのは、この解説。
このようなエピソードを聞くと、エッシャーが大の数学好きだったのだろうと想像してしまいますが、 実はその反対で、まるっきりの素人でした。その証拠に、ある学者がエッシャーの版画に使われている 法則について話をしても、エッシャーには全く理解できなったといいます。
信じられないことに、エッシャーのほとんどすべての作品に見られる数学の法則は、 エッシャーが制作をしながら自然と身につけたものだったのです
「トリック×トリック」ガイドブックより
数学苦手の私としては、大変に勇気づけられる言葉である。
妻: 自分をエッシャーと同一視してる？ 私: いや、そこまでは...でも、ちょっとね。
1.8.0のバグも気になるし、原稿の〆切も近づいているのだが、昼間はやっぱり遊ぶのだ。
というわけで、秋芳洞を訪問する。 ここのことは「あきよしどう」と発音する人と「しゅうほうどう」と発音する人の 両方がいるのだが、どうも「しゅうほうどう」の方が正統らしい。
完成するのに何万年もかかったという解説を聞きながら、 ばかでっかい洞窟を見てると、時間の観念がおかしくなる。 たかだか何十年という人生のタイムスケールを越えると適切に把握するのが難しい。
むしろ、観光のためにこんな洞窟をこっそり作ったんじゃないかとか、 今我々人類が見て楽しむ目的で自然の摂理が用意してくれていたんじゃないかとかの どちらかといえば馬鹿馬鹿しい考えの方に説得力を感じてしまう私の頭はきっとどうかしてるかも。
どうしても自分の生きている時代を特別と考える「現代セントリック」な考えと、 人類を特別扱いしてしまう「人類セントリック」な考えを持ってしまう。
いや、本当に特別なのかもしれないんで、むげに否定するのも変なのだが。
考えてみれば「人類セントリック」と「現代セントリック」は自分たちの信仰の一部でもあるんだし。
今日のバグは再現条件が厳しい。
returnの飛び先がおかしかった。具体的なコードとしては
def f(&b)
b.call
end
def g
f{return 42}+1
end
p g
のような感じ。
とりあえず対処したが、ブロック中のreturnの場合はbreakとは別に対処しなければならないような気がしてきた。
昨日まで遊び過ぎたので、今日はおとなしく。
買い物で立ち寄ったリサイクルショップでVisor Deluxが4000円。 ちょっと心引かれた。今のVisor Edgeがだめになったときのバックアップ用に欲しいかも。
でも、決心できずに買えなかったと言う。決断力がない。
休暇中とはいえ、バグレポートも〆切も遠慮なくやってくる。
家族の不評を買いながらも、深夜原稿を書いてたりするわけだ。
10月号の原稿のテーマは「オブジェクト指向」。この日記で書いたり、 ツッコミを受けたことを参考に初心者にもわかりやすいように書くように心がけたのだが、 ....読み返すとあんまり初心者にはわかりやすくはないかも。
だいたい用語が多すぎるんだよね。オブジェクト、メソッド、クラスなどなどなど。 しかし、オブジェクト指向という概念そのものがこれらの用語に依存しているので 説明しないわけにもいかないし。ぶつぶつ。
せめて実際に経験してもらおうとirbについても少々紹介してみた。 が、まだ規定のページ数には足りないみたい。もうちょっと。
その後、実家の近くの奥湯田温泉に入る。ひとり100円は安すぎ。
効能書きによると単純アルカリ泉らしいのだが、湯につかるとすべすべした感触があり、 いかにも温泉らしい気分が味わえる。玉造温泉は歴史はあるものの、お湯は普通だものなあ。
なんて、ゆっくりした気分を味わってはみたものの〆切が延びるわけではない。
で、原稿を書くためにirbを使っているのだが、補完機能が思いのほか便利で、 いまさらながら感動する。
ホームディレクトリの.irbrcに
require 'irb/completion'
という記述を追加すると、あら不思議、TABキーで識別子を補完してくれるじゃありませんか。
しかも、
foo.
の後ろでTABを押せば、変数fooの指すオブジェクトに応じてメソッド名を補完してくれます。 これ、最強。
これがあれば、他の対話環境はめじゃないなと。
山口から帰る。田舎の国道でも珍しく一部渋滞していたりしたので、思ったより時間がかかった。
途中、妻に運転を変わってもらったのだが、数分後、寝ぼけて交代したことをすっかり忘れていて、
なぜ私は運転中に寝ているのだっ
とパニックになってしまった。一瞬、居眠り運転で死ぬかと思った。びっくりして大声を出した。 家族もみんなびっくりした。
恥ずかしい。
今日は出雲支部の訪問の割り当て。
聖餐会の話は、経済的な話。わりと現実的なネタだが、できるだけ借金を避けようとか、 計画的に収入の範囲内で生活しようとか、感謝の気持ちを忘れないようにしようとか。
集会終了後、出雲支部の会計監査。無事終了。
Linux Magazineの原稿はようやっと片付けたのだが、 今月は実はもう一本引き受けていたのだ。 これは日経バイトの「技術の真髄」という記事で、 名前が知られている技術者に技術の動向等について 書いてもらうという企画なのだそうだ。
で、私には言語おたくとしてプログラミング言語の歴史と現状と未来についての依頼があった。まあ、好きなネタではあるので、 初心者に分かってもらえるだろうかなどの葛藤がないぶん、楽かも。しかし、これもお盆開けに原稿出すと約束しているので、すでに〆切が過ぎているのだった。メールで交渉し、数日期限を伸ばしてもらう。
先日来、書いてきた「技術の真髄」だが、 ようやっと今月分(前半)が完成した。
前半の内容は
などについて。 目新しい内容としては世界最初のプログラミング言語Plankalkulについてくらいかな。
後半も書かなきゃ。
島根大学で開催される「Linux体験講座」に参加する。
いや、私が体験するんじゃなくて、TAとしての参加。 講師の縄手先生には普段からお世話になっているので、 井上社長とともにお手伝いということで。
でもなんとなくスタッフのために用意されたお弁当が目当てだったような気がする。(苦笑)
ええ、皆さんがLinux(GNOME)を体験するのをお手伝いしましたとも。いやあ、実は私がGNOME初体験だったりするのですが。しかも、講座中に日記更新してたりするし。
松江に帰省中のmputさんが会社に遊びに来てくださる。
timitidytimidityのプロジェクト管理の話など、興味深い話をたくさん聞く。
やはり、どこのプロジェクトでも同じような経験をするのね、とか思ったり。
でも、私が中心になっているRubyと集団管理体制のプロジェクトでは、また違った側面もあるようだ。 それとsourceforge遅いとか。やはり自前で用意する方が良いのか。compile farmだけはうらやましいと思う。
仕事柄、年に2,3度海外に行って、Rubyについて話したり、議論したりする。 また、毎日のように英語のメールを書いているわけだ。
にもかかわらず、私の脳にはすべて日本語で記憶される。
日本に帰ってから「こんな話をしたよ」と説明していると、 「で、それ英語でどう表現するの」と聞かれると答えられなかったりする。 どうも短期記憶から長期記憶に移行する時に自動的に翻訳されるらしい。
だから英語が上手にならないんだ。
記憶と言えば、私は歌の歌詞を覚えることができない。 メロディーはすぐに覚えるんだけどなあ。
木曜の夜から次女が妹夫婦のところに泊まりに行っている。 5人家族のうち、ひとりがいないだけでずいぶん寂しいものだ。
出かけている方は新しい経験の真っ最中なのでそれほどでもないようで、 わりとそっけない。電話でも「ちょっと寂しいよ」くらいか。
残された方は普段と同じ生活なのにいるべき人がいないので喪失感がある。 なんか足りないなあ、とか。 思えば一人暮らしを始めた時には親や家族に同じような思いをさせたのかなあ。
ひさびさの松江出席だが、聖餐会でお話してくれと依頼される。 うう、自分のワードに来た時くらい人の話を聞いていたいんだけど。
テーマは聖典。今は簡単に聖書が手に入るが、昔は写経するしかなかったし、 そもそも中世の教会は一般信徒の入手を禁止していた。 書いた預言者たちも、書き写してきた人たちも大変な苦労をして、 今の聖典が存在する。それくらい大切なものなのに、自分を含めてあんまり大切にしてないよなあ。 あらためて感謝しよう、とかいうような話。
息子はお気に入りの先生がお休みだということでクラスに出たくないとごねる。 誰に似たのか人見知りが激しい。感受性が豊かということだと思うことにする。
matjuことMathieu Bouchardが、「Rubyに本物の多重継承を」と提案している([ruby-core:1378])。
基本的な主張は
というようなことなのだが、私の答えは「気持ちは分かるが賛成できない」である。
というのも、Rubyのmoduleのような制約によってMix-inを強制した方が、 クラスの階層構造のデザインがきれいになることを支援できると考えているからだ。
しかし、改めて考えると、「なぜその方がきれいになるか」とうことを上手に説明できない。
継承のラインとMix-inのラインを区別することで、単純(単一)継承のシンプルさと、 多重継承の機能の両方を実現できる、というのが一応の答えだが、本当にそうか、証拠があるか、 と問われると答えに窮したりして。
結局matjuはあまり賛成が得られなかったということで、この提案を引っ込めてしまうのだが、 将来の考察の材料にはなったと思う。
Mix-inは本当に多重継承より優れているのか
今後も考察を続けたい。
最上さんの日記で、 私が書いていることについての疑問点をリストしていらっしゃる。 分からないのは、私が書きなぐった日記を時間をかけて考察しているからではないかと(苦笑)。
これらの記事を読むと「アイデンティティがあること」と「リファレンスあるいはポインタ値があること」と「代入によってコピーが発生しないこと」がほぼ同じ事とされているように思う。しかし本当にこれらは同じことなのだろうか。これが第一の疑問点。しかもこれらがオブジェクト指向の必要条件とされている。
同じじゃないかも。私が同じでない例を思いつかなかっただけで。
これらが必要条件かというとそれは微妙で、 RubyにおけるFixnumの実装などを考えると、アイデンティティがないオブジェクト指向は不可能ではないと思います。 しかし、それはあくまでもtrivialなケースだけで、アイデンティティがない(よって副作用もない)状況で、 実用的なオブジェクト指向プログラミングは不可能ではないかというのが私の意図です。
その辺が、以前「アイデンティティ」で「副作用の全くないオブジェクト指向プログラミングというのは、なかなか考えにくい」と書いた真意なのです。
第二の疑問はこの条件を満たさなくてもオブジェクト指向と呼べる場合があるのではないかということ。例えばC++ではクラスメソッドの内部以外では一切ポインタを使わないことにしてobject.method(arguments); と言う形の呼び出しを使って全てを済ませることが出来る。可変長のものを扱わなくて良いのならクラスメソッドの内部でもポインタを一切使わなくて良い。この場合はアイデンティティはない。ポインタ値もない。代入によってコピーが発生する。でもこれでも充分オブジェクト指向ではないのか。それともなにか見落としているだろうか。
「object.method(argument);という形」がどういう形なのかいまいちよくわからないのですが、 objectというのはスタック上のオブジェクトであるということなのかな。 仮にそうだとしてもC++だとメンバ関数にはthisというリファレンスが暗黙に導入されちゃっているんで、 「ポインタ値もない」とはいえないんじゃないかと。
仮に「メンバも一切使わない」のだとすると、 それだけで実用的なオブジェクト指向プログラミングができるとは私には思えません。 つまり、「不可能」ではなく「実用的ではない」ですね。 動的結合も副作用さえも使えないわけですよね。
追記
あれ、もしかして「アイデンティティがない」って表現を、 「アイデンティティがないものがある」という意味で使ってます？
私は「アイデンティティがないものしかない」という意味で使ってます。 アイデンティティがあるものとないものが混ざっている場合には、 オブジェクト指向するのになんの問題もないので。
scanfの辺りで悩んだことからきているのだが、また多重代入の挙動で悩んでいる。
いろいろな条件が重なっているので、全体として見るととても複雑で、 自分でも「なんでこうなっているんだろう」と悩むような部分があり、 何ヶ月かおきに「挙動を変えよう」と思ったりする。
しかも、こんなすみっこの挙動に関心を持つ人がいないので、誰にも相談するわけにもいかず (akrさんなら気が向けば考えてくれるかも)、結局自分一人で考えるしかない。
今回問題にしているのは
"a".scan(/(.)/){|*a| p a}
の出力が[["a"]]なのに、
"ab".scan(/(.)(.)/){|*a| p a}
の出力が["a", "b"]である点だ。
いっそ多値でも導入しようかという気にもなるのをぐっと押さえて、いろいろ考える。 結論としては
というもの、これで後者の出力は[["a", "b"]]になる。 多重代入では
a,b = 1,2 a,b = [1,2]
は同じように動作するので、この変更による影響はあまり大きくないと思う。 いや、本当に大きくないかはやってみないと分からないな。 実際に修正して、試してみよう。「ぎゃっ」と言う人が多ければ考え直すことにして。
いくつかツッコミをもらいました、どうも。
まず、ゆあいさんのツッコミから。
アイデンティティが重要なのは、アイデンティティがあるオブジェクトと無いオブジェクトでは、 コピー時の動作が大きく異なるからではないでしょうか？
まあ、そういうこともあるでしょうが、 私が重視している理由は「アイデンティティがないものはオブジェクトではないだろう」ということです。
「オブジェクト指向」というからには「オブジェクト」を意識しないといけないわけで、 そのために最低限必要なものはなにかと考えた時に行き着いた概念が「アイデンティティ」です。
アイデンティティという観点からプログラミング言語(というか計算モデル)を分類すると
と分類できますが、オブジェクト指向するにあたって、(1)は問題なし、(2)はアイデンティティがないものも「その値がアイデンティティである」と考えて(1)に準じる、とすることができて、(3)ではちょっと無理だろう、というのが私の仮説です。
最上さんのツッコミでは、
というC++のサブセットを考えておられるとのことです。 私はこの言語におけるプログラムがどのようなものになるのか想像できないのですが、 実際のところどうなんでしょうね。この言語には本当にアイデンティティがないのでしょうか。
実際には、暗黙のポインタによってアイデンティティが導入されてそうな気がします。
さて、最後にともさんのツッコミです。
アイデンティティが無くて、メンバーはあるけど単一代入で、メッセージ送信はマルチキャストがデフォルトな言語ってどうでしょうか?割と実用的に書けるんじゃないかという気がするんですが。アイデンティティが必要ならそのためのメンバーを書けば利用者がアイデンティティのようなものを使うことはできるし (現実世界ではアイデンティティはそんなに自明じゃなくて、代用品でまにあわせている気がするし)。
これは難しい。
なにが難しいって、おそらく非常に高度な概念を短い言葉で記述してあるので、全体像が想像しにくいことです。
アイデンティティがない
参照がないという意味なのでしょうか。 そもそもアイデンティティがない言語というのが(古い)FORTRANのような 低レベルのものか、純粋な関数型言語くらいしか思いつかないのですが。
メンバーはあるけど単一代入
「単一代入」は分かりますが、メンバーの単一代入というのはどういう意味でしょうか。 初期化時にメンバの値を指定してその後は変えることができないということかな。 Pythonのタプルとかのようなimmutableなオブジェクトを想像しちゃいます。
メッセージ送信はマルチキャスト
これが一番分かりませんでした。複数のレシーバに同時にメッセージを送るという意味だと思うのですが、 「複数のレシーバ」という概念にすでにアイデンティティが含まれていると思うのですが。
ということで、もしよければこのアイディアについていろいろ聞かせてください。
ちなみにこういう場合、「アイデンティティがある」ことになるんでしょうか?個人的にはオブジェクト指向するのに必須かどうかで議論した方が良い気がするんですけど。
すでに述べたように「オブジェクト指向という考え方の最低限」がアイデンティティだと思っています。 アイデンティティのない言語でもオブジェクト指向はできると思っていますが、 そのためにはユーザレベルでなんらかのアイデンティティを導入する必要があると思います。
一つの例としてTclがあります。Tclにはデータ型として文字列しかありません。 数値やリストなどは文字列として表現します。少なくとも表面的には。
で、Tcl上のツールキット(Tk)には「ウィンドウ」とか「ボタン」とかいったような「オブジェクト」が 登場するのですが、どのオブジェクトが明示するために「パス」というものを使います。 たとえば「.frame.panel.button1」のような感じですね。これはTcl的には文字列に過ぎないのですが、 Tkにとってはあるオブジェクトを指し示す参照でありアイデンティティです。
JAOO2003のチケットの手配終了。最終的には向こうが払ってくれるとはいえ、結構な額を立て替えることになる。
もっと重要人物になれば自分で苦労しなくても向こうでチケット手配してくれるようになるんだろうか。 あまり期待できそうにないな。
もうそろそろアイデンティティの話はもういいかなって気持ちになってるんだけど、 乗りかかった船なんで最後にまとめておこう。
わたしが「アイデンティティがない」という時には以下のことを意味しています。
たとえばTclのような言語は、言語機能としてアイデンティティがありません。
ふと思い立ってeval.cの大改造。変更した点は以下のとおり
試行錯誤でコーディングしているので、ここを直すとあちらが動かずなどということを繰り返しているうちに、 次第に全体像が頭に入ってきて、あるべき姿を理解できるようになった。こういうコーディングしているから、 いつまでたってもバグがなくならないんだろうなあ。
で、改造結果だが、構造はやや単純になったが、別に速くなったわけではないと思う。 しかし、なんだか達成感がある。
私がRubyをハックしているかたわらで、妻は手芸にいそしんでいた。夜中の3時まで。 お互いに夜更かしが過ぎます。
知人の家で流しそうめんをやるということで、お誘いを受ける。 本当は8月9日の予定で、LL Saturdayと重なるので無理だと思っていたのだが、 例の台風のおかげで今日に延期になっていたのだ。 あの台風にはひどい目にあわされたが、いいこともあるのだな。
あいにく天気はあまり良くなく、小雨混じりの天気であったが、決行。
竹を割って樋のようなものをつくり、器を作り、箸を作り、水とそうめんを流す。 途中から水遊びを始める子供たちもいたし、庭の家庭菜園を探検するものもいた。
後には、泥だらけの靴、びしょぬれの服、虫さされの痕。
大人も子供も楽しんだ。
ruby-listで「変数=箱モデル」の優劣についての議論がある。 まあ、あくまでもたとえなんだから、完全なたとえはありえないわけだが。
箱モデルについて考察すると、まず前提としては
ということがある。これは別に問題ない。 私がCの解説書を書けと言われたら、変数の解説には箱モデルを使うだろう。
問題はそれをRubyの解説書に適用するのが適切かどうかだ。 これはもちろん読者のバックグラウンドによって違うだろう。
すでに箱モデルになじんだ人にとっては箱モデルの解説に意味があるのは確かだが、 問題は
ということだ。やっぱり、Rubyを題材にした解説本に箱モデルは有効ではないんじゃないかなあ。
ただし、反論の中にはいくつか興味深いものがあるので、引き続き考察してみる。
配列は普通箱の並びとして図示するので、気持ちは分かる気がするけど、 「名札が並んだもの」でも別に困らないと思う。
一番心配するのは、箱モデルでは変数に箱という実体を与えてしまうため、 変数がオブジェクトであると認識させてしまうのではないかということ。 変数が実際にオブジェクトであるCのような言語でない限り、じゃまにしかならないような。