Linux Magazine 7月号の原稿はさきほどしあがりました。
予告通り、タイトルは『XMLとYAML(その2)』。 この日記での議論もある程度反映したものになっています。 みなさん、ありがとうございました。
[ruby-talk:71112]などでSimon Strandgaardくんが要求していることが ずっとわからなかったのだが(お互い英語は得意じゃないし)、 しばらく彼のメールを読むうちにやっと分かってきた。
要するに彼はRubyインタプリタをC++プログラムに組み込むことを行っているわけだが、 その時に、$stdin, $stdoutなどに代入した効果をRubyの中だけで閉じたい、と考えているようだ。 これは
ということから来ているもののようだ。しかし、いくら組み込みだとはいえ、
stdinなどはプロレスプロセス全体でひとつずつしか持てない資源なわけで、
それをRubyの世界の中だけで繋ぎ換えるのは無理な話である。
彼にはあきらめてもらうしか。
しかし、それはそれとして、この議論は私には有意義であった。 つまり、Rubyに足りないと思われる点がいくつか見つかったからだ。
ひとつは、エラー出力のリダイレクトである。Rubyの通常出力(printやputsのデフォルトの出力先)は、 すべて、変数$defoutという変数に格納されたオブジェクトに対して行われる。 このオブジェクトは必ずしもIOである必要はなく、writeメソッドを備えていれば良い。 しかし、エラー出力に対しては問答無用でstderrに出力していた。 しかし、一貫性の観点や便利さから言えば、同様の仮想化が行われるべきだ。
ということで、新たに$deferrという変数を用意し、エラー出力はすべて、ここを通すようにした。 さらにwarnメソッドも新設した。その動作は
$deferr.write(s)
$deferr.write("\n")
と同じである。
もうひとつは標準入出力を切り替えることのできるsystem関数である。 すでにOpen3というライブラリはあるのだが、これのあり方も含めて再考したい。
最後に変数$stdinなどである。現在はこれらの変数に代入すると内部的にreopenを行っている。 しかし、この動作がSimonの誤解を招いたと言う事実は否定できない。 むしろ、これらの変数はread-onlyにして、警告などを使って、 最終的にはSTDINなどを使うように誘導した方が良いような気がしてきた。
間違いを招くような機能はむしろない方が良いし、それを放置しないことが良い言語であり続ける秘訣だと思うのだ。 これを「broken window theory」と呼ぶ。
そういえば、Rubyを直したい点というのがもうひとつある。 正確にはひとつだけではないが、今日になって改めて思い出したものがひとつある。
それはメソッド結合である。モジュールをincludeしたとき、そのモジュール独自の初期化を行いたい場合がある。 そのような場合、現在のRubyならinitializeメソッドを呼ぶことになるだろう。 しかし、どのようなクラスにincludeされるか事前にはっきりとはわからないモジュールでは、 includeするクラスがinitializeでsuperを呼んでいないかもしれない。 そうするとそのモジュールのinitializeは呼ばれず、 オブジェクトは初期化されていない半端な状態で取り残されることになる。
superを呼ばなかったのがいけないんだ、と責任をユーザに押しつけるのは簡単だが、 多重継承に近いモジュールで呼び出し関係を維持するためsuperが必要か必要でないのか悩むのは、 プログラマの時間がもったいない。
他の言語ではこれらの問題をどう解決しているかというと、
こっちの方がスマートだ。
Rubyでもなんらかの方法で解決策を提供したいが、どのような機能、記法が良いのかは、 まだだいぶん思案しないといけないだろう。メソッド結合が良さそうなんだけど。
あるいは1.7から導入された define_method と同じような形で、 たとえば define_hook (あるいは define_advice) というメソッドを用意するのはどうだろう。
module Foo
define_hook(:initialize, :before) { p 44}
end
class Bar
include Foo
def initialize()
p 55
end
end
bar = Bar.new
# => 44
# 55
が、before hookで44を出力し、initialize本体で55を出力するわけだ。もちろん、after hookも定義可能とする。 が、around hookはいらないだろう、きっと。
でも、define_method同様、いや、それ以上に醜いと言うのは欠点だ。
先日、正規表現の「$」が「改行と文字列終端の間」にもマッチするように変更したのに合わせて、 「\Z」も同様に「改行と文字列終端の間」にもマッチするようにしました。
〆切前の逃避行動で、今日から導入してみたのだが、昨日のエントリに対して
とかの広告が出るのはいかがなものか。
やはりアレか、「人の生命に直結する」なんて書いたせいか。
すいません。遅れてます。
録画しておいたものをようやっと見るが、えー、なんなんでしょう、 完全に独自路線ですか。なんか原作での謎があっさり明らかになったり、 出てこない超重要キャラクタとかいるんですが。
子供がアニメをまじめに見るようになるまで、ずいぶんアニメを離れていたのだが、 その間にこういうのは普通になってしまったのだろうか。
漫画とテレビの乖離としては、
などは思い至る*1が、 この『鋼の錬金術師』はそのどちらにもあてはまらない。 原作よりもペースが速く(漫画は月刊だものな)、 しかも原作とは独立の作品にしあがっている。 しかも、個人的な感想では原作に負けないくらいストーリーが面白い。 というか、スピード感があってこっちのほうが好きかも。
*1 例が古くて偏っているのは、ほら、年寄りだから
この「Matzにっき」の検索をtdiary grep検索から、Rastによる検索に変更してみた。
N-gramベースの検索なのでgrepと同等の使用感が得られるはず。 また、インデックスを使っているので検索速度はずいぶん向上しているし、 スコアリングも追加されたし、いいことだらけ、のはず。
不具合があれば報告してほしい。
「まつもと直伝 プログラミングのオキテ」第三回。
元々この連載は「オブジェクト指向のオキテ」というタイトルが(編集から)与えられていたのだが、 「それだとオブジェクト指向以外の話ができないからやめて」とお願いして、 直前にタイトルを変更してもらった経緯がある。
しかし、まあ、そういうタイトルをつけたくなったのもわかるくらい当面はオブジェクト指向ネタが続くのだった。先月はプログラミング抽象化の延長線上に継承を定義するという、やや乱暴かつ歴史の実態を反映していない(が考え方としては間違っていない)内容だったが、今月はそれを受けて、 多重継承について。
元々多重継承の多用にはあまり賛成でない私だが、しかし、単一継承*1ではなく、多重継承でなければ解決できない問題があるのも確かだ。単一継承で起きる問題、多重継承で起きる問題の両方を提示して、「じゃあ、どうすりゃいいのよ」ということを書こうという内容なのだが、ていねいに説明しようと思うとまわりくどい。が、きびきびと書き進むと他人にはわからない、なかなか難しいものだ。
〆切は月曜日。
*1 本連載ではsingle inheritanceの訳語を従来の単純継承ではなく単一継承に統一した
娘の自転車がパンクしたということで、 ずいぶん久しぶりにパンク修理をした。 ゴム糊がぜんぶ揮発していて新しいのを購入する必要があったり、 トラブルもあったが無事修理。
しかし、最初チューブを出して全部水につけても穴を発見できず、 かなりあせった。虫ゴムなどが悪いのかと思ったが、 そこも異状はないようだ。
ふと思って、空気を強めに入れたらはじめて空気がもれだしてきた。 試しに入れた弱い圧力では穴がふさがっていたらしい。
これから得られる教訓は「ストレステストのストレスは十分に」か。
ちなみにエントリタイトルはブラックジャックの『弁があった』から。 Dr.キリコのお父さんが出てくる回ね。
ラベリングの話。
「Digital Rights Management」というと「私の権利」が守られるような印象があるが、 実際に守られるのは「コンテンツホルダの権利」であって、 私の権利はむしろ制限される。
これはよくあることで、「活用」と「利用」とか、「希少」と「異常」とか、 「普通」と「凡庸」とか、 言い換えるだけでえらい印象の変わる言葉はいくつもある。 安易なラベリングには気をつけよう。
詭弁のガイドラインに含めるべきだな。
さりげなくポジティブなイメージの言葉を使う。
「権利」と「保護」というポジティブな言葉を組み合わせる(誰の「権利」か明示しない)ことで、 ユーザから権利を奪うことを目立たせなくする。
さりげなくネガティブなイメージのある言葉を使う。
「普通でない」を「異常」と呼び、 「異常だから悪い」と展開する。
今日の聖餐会は母の日特集であった。
いろいろな人が母に関する思い出や経験を語ってくれた。 母の愛は偉大だ(そうだ)。
うちも両方の母に小さな贈り物をした。
次女はお菓子を作って妻に感謝の気持ちをあらわしていた。