Ruby、君はオブジェクト指向なんかじゃない、謎の生命体試行錯誤だ！
昨日の調査では謎の生命体「Fixnum:1」ー固定番号:1と呼ぶのは止めたこっちのほうが謎めいた名前でいいだろ？ーに関する、いくつかの貴重な発見があった。その中でも特に重要と思われるものは次の２点だ。
- 「Fixnum:1」が他のFixnumら ーつまりFixnum:2から少なくともFixnum:100まで ーの情報をすべて持っているということ
- 問い掛けを繰り返すことによって他のFixnumの情報を取得することができるということ
僕は昨日ベッドに入ってからも、これらのことが気になってなかなか寝つけなかった。特に最初の点について彼がその外観からして、他のものの情報をすべて持っているというのは、僕の常識からみてどうにも納得がいかない。外観で人を判断しちゃいけないってことは僕もよくわかっている。ー子供のときそのことで随分とこっぴどく叱られた記憶があるーまた僕の偏狭な常識でこの問題を判断するのもどうかと思う。けど、理解というものはそれを自分の常識の中に持ち込めないと、先に進めないというのもまた事実なんだよ。
待てよ…
そうか！
彼が持ってるんじゃないんだ。僕が彼に問い掛けたときに、彼もまた誰かにそれを問い掛けてるんだ。彼は彼の仲間と交信する手段を持っている！そうに違いない！
この仮説が正しいとすると新たな２つの疑問が首をもたげる。いったい誰と？そしてどのようにして？誰と交信しているかという問題に関しては、２つのことが考えられるだろう。１つは当然nextのFixnum:２だ。
例えば僕がFixnum:1に。
$ 1.next.__id__
としたときに、Fixnum:1は自分ではその問いに答えられないので、1.next =>2に基づいてFixnum:2との交信を開始する。そして彼に以下のようにしてその問いを渡す。
$ 2.__id__
Fixnum:2はFixnum:1からのこの問い掛けに対して、
$ => 5
を得てこれを返答する。Fixnum:2からのこの返答を受けたFixnum:1は、これを僕に返答する。こういった仕組みだ。
ただこの方式には一つ重大な欠点がある。昨日僕がやったように、Fixnum:1に対してFixnum:100の階級を問い掛けた場合、上の面倒なプロセスを100回も繰り返さなきゃならない。しかももし途中の誰かがさぼったり不在にしてしたら、この方式ではうまく情報が伝達しない。人間の社会じゃ、そんなシステム設計をしたヤツは即刻クビだ。それとも彼らの社会では「もし…」なんて起きないんだろうか？
もう一つ交信相手として考えられるのは彼の上官だ。Fixnum:1は職務階級Fixnumに属している。そこで彼はその職務階級に則した特別な訓練を受けている。その訓練を彼らに施しているものが当然存在するはずだ。この場合の情報伝達プロセスは次のようになるだろう。僕がFixnum:1に、
$ 1.next.__id__
としたとき、Fixnum:1は自分ではその問いに答えられないので、彼の上官との交信を開始する。そして次の問いを投げる。
$ next.__id__
上官は職務階級Fixnumに属するすべての固定番号の情報を保持しており、従ってFixnum:1のnextがFixnum:2であると直ぐにわかる。上官はFixnum:2の社会保障番号を保持しているかもしれないが、保持していないとすればそのときはFixnum:2と交信して問い合わせればいい。こうして得られたFixnum:2の社会保障番号5は、上官からFixnum:1に伝えられFixnum:1はこれを僕に返答する。
こういう連絡系統にしておけば、仮に僕がFixnum:1にFixnum:100の情報を問いかけたとしても、彼とFixnum:100との間に介在するのは信頼のおける上官一名だけだ。その結果情報伝達の確実性とスピードは飛躍的に向上するだろう。
まあいずれにしても、現段階ではそれを解明する手段を僕は持ちえないし、それがわかったところでこの壮大な謎の解明にはあまり役立ちそうにない。
いや、ちょっと待てよ。例のchain talkingを使えば、上官の情報が得られるかもしれないぞ。上官の情報が得られればそれが解決の糸口になるかもしれない。
早速やってみよう。おそらくこれが上官にたどり着く問い掛けだろう。
$ 1.ceil
あれ？
$ => 1
ceilというのは当然「天井:ceiling」という意味だ。nextが同級の隣のヤツを指すのだから、ceilは天井ーつまり上ーのヤツー上官ーを指すmethodだろう普通。ちなみにfloorというmethodもあるから、これはceilと対になっていて、下のヤツー下官ーを指すものだと思っていた。
$ 1.floor
違うのか？
$ => 1
いずれも1、自分自身とはいったいどういうことなんだ？
何か他に手だてはないか…
そうだ。職務階級classの方から攻めてみよう。これは有効だろうか？
$ 1.class.__id__
あっ！
$ => 100420
社会保障番号が返ってきたぞ！これはどういう意味なんだ？職務階級に社会保障番号があるって…
そうか、Fixnum:1の職務階級を表すFixnumはそれ自身が上官のことなんだ！つまりこれは学級で、Fixnum先生のクラスをFixnumと呼ぶようなものだ。ーたぶん上官に愛着を持ってもらおうという意図からーそういうことに違いない！
よしこうなったら、Fixnum上官のことを少し調べてみようじゃないか。まずは彼の職務階級 ーそれは同時に彼の上官を指すー を聞いてみよう。
$ 1.class.class
どうだ。
$ => Class
これは？問い掛けに失敗したのか？こちらの問い掛けが戻ってきているようだ。
いや違う！よく見ると大文字から始まっている。classじゃなくてClassだ。つまり、Fixnum上官の上官はClass上官なんだ！
こうなると更に上を調べたくなるのが人情ってもんだ。それっ。
$ 1.class.class.class
あれれ？
$ => Class
Class上官の上官はClass上官？これはおかしいな。もういっちょいって見るか。
$ 1.class.class.class.class
$ => Class
なんだ行き詰まっちゃったな…
そうか、行き詰まりなんだよ！つまりClass上官が最上位の上官、最高司令官なんだ！最高司令官Classの下にFixnumがいる。そしてFixnumの下に彼Fixnum:1がいる。なるほど、割とフラットな組織だな君たちの組織は。
命令系統がわかったところで、Fixnum上官のことに戻ろう。彼のサイズはいくつかな？
$ 1.class.size
これはいったい？
$ NoMethodError: undefined method `size' for Fixnum:Class
どういうことだ？！
なるほど…そういうことか。この答えの可能性は２つある。１つはFixnum上官は女性であるということだ。女性特に年ごろの女性はサイズを聞かれるのを嫌う。したがって回答を拒否するということは当然にありうるし、僕が最初からFixnum上官が女性であることがわかっていれば、こんな失礼な質問は投げなかった。そうであればこの問題についてはこれでおしまいだ。僕は紳士としてこれ以上立ち入らない。
しかし問題はもう一方の可能性についてだ。もう一つの可能性はこうだ。
ーFixnum上官にはサイズがないー
先の回答はそれを意味している可能性がある。仮にこの考え方が正しいとすると、Fixnum上官は社会保障番号を持った実在であると同時に、空間を占有しない観念的な存在であるーつまり実在しないー。これは完全に僕の理解を超える。
したがって確定的ではないが、Fixnum上官は女性説が今のところ有力だ。
さて、もう少しFixnum上官のことを調べてみよう。彼女 ーとりあえず女性説を採用しようー も、多数の問い掛けmethodを持っているに違いない。
$ 1.class.methods
よし！
$ => ["inspect", "private_class_method", "const_missing", "clone", "method", "public_methods", "public_instance_methods", "instance_variable_defined?", "method_defined?", "superclass", "equal?", "freeze", "included_modules", "const_get", "r", "methods", "respond_to?", "module_eval", "class_variables", "dup", "protected_instance_methods", "instance_variables", "public_method_defined?", "__id__", "object_id", "eql?", "const_set", "id", "singleton_methods", "send", "class_eval", "taint", "frozen?", "instance_variable_get", "include?", "private_instance_methods", "__send__", "instance_of?", "private_method_defined?", "to_a", "name", "autoload", "type", "ri", "<", "protected_methods", "instance_eval", "<=>", "==", ">", "display", "===", "instance_method", "instance_variable_set", "kind_of?", "extend", "protected_method_defined?", "const_defined?", ">=", "ancestors", "to_s", "<=", "public_class_method", "allocate", "hash", "class", "instance_methods", "tainted?", "=~", "private_methods", "class_variable_defined?", "induced_from", "nil?", "untaint", "constants", "autoload?", "is_a?"]
彼女は77個のmethodを持っていた。ちょっとこれをFixnum:1のmethodと対比してみよう。
$ 1.methods
$ => ["%", "inspect", "<<", "singleton_method_added", "&", "clone", ">>", "method", "round", "public_methods", "instance_variable_defined?", "divmod", "equal?", "freeze", "integer?", "chr", "*", "+", "to_i", "methods", "respond_to?", "-", "upto", "between?", "prec", "truncate", "/", "dup", "instance_variables", "__id__", "modulo", "object_id", "succ", "|", "eql?", "zero?", "~", "id", "to_f", "singleton_methods", "send", "prec_i", "taint", "step", "to_int", "frozen?", "instance_variable_get", "__send__", "^", "instance_of?", "remainder", "to_a", "+@", "nonzero?", "-@", "type", "**", "floor", "<", "protected_methods", "<=>", "instance_eval", "==", "prec_f", "quo", ">", "display", "===", "downto", "id2name", "size", "instance_variable_set", "kind_of?", "abs", "extend", ">=", "next", "to_s", "<=", "coerce", "hash", "ceil", "class", "tainted?", "=~", "private_methods", "div", "nil?", "untaint", "times", "to_sym", "[]", "is_a?"]
僕はこの２つのリストを比べてみることにした。アルファベット順に並べ替えて見比べてみる。その結果、２つのリストのうち45個のmethodは共通し、彼女固有のmethodは32個、Fixnum:1に固有のものは48個あるということがわかった。
この作業の過程で面白いことに気がついた。それは彼女のリストには、昨日Fixnum:1に問い掛けたnextというmethodが存在しないということだ。これは何を意味するのかというと、彼女Fixnum上官には隣のヤツがいない。そういう意味だ。おそらく左隣ーpreviousーのヤツもいない。彼女は職務階級Classに属するが、寂しいことにClassには彼女の同僚と呼べるようなヤツはいない。
一方で、Fixnum:1のmethodには存在しなかったnameというmethodがある。これを問い掛けてみると、
$ 1.class.name
$ => "Fixnum"
そう、彼女の名前が返ってくる。やはり管理職という立場には、パブリックな名前を通してしかその存在が意識されない、ある種の悲哀のようなものが漂うな。でもまあこれで、君たちの世界がそれほど広大なものではないということがわかったよ。
もう一つユニークな問い掛けを彼女のリストに見つけた。ancestors ー祖先ー だ。これほどわかりやすい問い掛けもないな。nameに次ぐわかりやすさだ。
$ 1.class.ancestors
むむっ。
$ => [Fixnum, Integer, Precision, Numeric, Comparable, Object, Kernel]
先の調査でFixnum上官の上官はClassであり、Classは最高司令官であることがわかっている。そうするとここに出てきた祖先たちは命令系統における祖先ということではなくて、Fixnum上官のプライベートな祖先のことなのか？
彼らは現存するのだろうか？そうだとすると極めて厄介なことになるな…今はただ、皆さんが既にお亡くなりになっていることを祈るばかりだ…
さて夜も更けてきたので今日はこれくらいにしよう。
っと、思った矢先にsuperclassという無視できないmethodを彼女が持っていることに気がついたじゃないか。class ー職務階級ー じゃなくてsuperclass ー超職務階級ー だ。はて何が出てくるのだろう。
$ 1.class.superclass
ありゃ。
$ => Integer
さて困った…
Integerはプライベートな祖先じゃないのか？Fixnum上官の職務階級がClassで、超職務階級がIntegerとはどういう意味だ？
わからん…
今日のまとめをしてもう寝たほうがよさそうだな…
- Fixnum:1はFixnum上官と何らかの交信手段を有しておりこれによって他の同僚の情報を取得できる
- Fixnum:1の職務階級名Fixnumは同時に上官の名前である
- Fixnum上官は職務階級Classに属しそのClass上官は組織の最高司令官である
- Fixnum上官はおそらく女性である
- Fixnum上官の祖先はInteger, Precision, Numeric, Comparable, Object, Kernelであるーこの順位にも意味があるものと思われる
- Fixnum上官の超職務階級はIntegerである ーなおIntegerは祖先でもある
blog comments powered by Disqus
