«前の日(11-12) 最新 次の日(11-14)» 追記

Matzにっき


2003-11-13

_ [Ruby]Texas A&M University

ホテルで朝食をすませた後、Stroustrup教授の車で大学まで。 大学を一周して見物させてもらう。

しかし、広い大学だ。筑波大もいいかげん大きいなあと思っていたけど、 ここはその何倍も広い。冗談のような大きさのスタジアムが印象的だった。

Bjarneいわく「キリスト教はテキサス州2番目の宗教だ。最大はフットボール」だそうで、 熱の入れ方は半端ではないそうだ。

午前中はBjarneの紹介で、Salih Yurttas教授と会う。 「今度は授業でPythonを扱おうと思ったけど、Rubyにしようかなあ」とおっしゃっていた。 言語好き同士話が弾む。

昼食をBjane、Salihと一緒にとった後、今度はComputer Science Dapartmentのディレクター、 Valerie Taylor教授に紹介される。

しかし、いくらわざわざ海外から来た客だとはいえ、 実質的に無名な私にきちんと時間を割いてくれる丁寧な扱いに感銘を受ける。 しかも、コンピュータ科学部のボスまで。感謝。

Valerieは

私はずっとAWKなの。 研究してるシステムはPerlを使ってるけど、開発は学生がやってるから。

とのこと。

今回は夕べのディナー、今日の朝食、昼食とずっとBjarneと一緒だった。 せっかくの機会なので聞いた話をまとめておこう。思い出せることを端から書き上げたので、 順不同、時系列無視なのであしからず。

Matz(以下M): C++にはSimulaの影響が見えますけど、他のオブジェクト指向言語、 たとえばSmalltalkからは影響を全然受けていないんですか?

Bjarne(以下B): 受けてないね。 私は元々(ケンブリッジ大の大学院で)分散システムの研究をしてたんだけど、 分散システムのシミュレータを書くのにSimulaを使ったんだ。 ところがSimulaは遅すぎて結局BCPLで書き直したんだけどね。 こういう経緯があるんでCにSimulaの機能を追加したC with Classを作り、 最終的にはC++になったというわけなんだ。

M: Javaについてどう思いますか? (Aarhusでも聞いたけど)

B: 聞かないでくれ。もしPositiveなことを言えば、そんなので満足してるかって言われるし、 Nagativeなことを言えば波乱が起きるし。 15年くらい前にはObjective-Cの連中といろいろあったし。 言語論争は嫌いだ。

M: そのObjective-CのBrad Coxが今JavaとRubyを使ってるっていうんですから皮肉ですよね。 今なにを研究してるんですか。

B: 今は他のプロジェクトを助けたり、会議したりしてるんだ。院生を指導したりもしているよ。 こっち来てから1年くらいにしかならないんで本格的な活動はまだだね。 また分散の研究をしようかなあって思ってるんだ。 あと、大学っていうのは研究だけじゃなく教育もやるところだからね。それについても活動しているよ。

M: というと?

B: 来年そうそうから学部生の授業を持つことになってるんだ。C++を教えるんだけど。 で、いい教科書がなくてねえ。困ってるんだ。 C++を使った教科書はどれも分厚いばっかりで面白くないし。 たとえばこれなんか「回文チェック」って例題のために、 擬似コードでの回文とはなにかって説明に2ページ、C++のプログラムにまた2ページ使ってるんだよ。 テンプレートを使えばこんなのワンライナーなのに(と黒板に書きはじめる)。 おまけにこれなら任意の型のベクターの回文チェックができる。

B: 今は学生のためにGUI機能を設計してるんだ。 今時の授業じゃGUIを使わないわけにはいかないけど、 私が授業でやりたいのはツールキットの説明じゃない。 既存のツールキットをそのまま使ったらその説明時間だけで授業が終わっちゃうからね。 ダイアログを呼び出す同期呼び出しとポーリングを使った非同期呼び出しができる単純なものを考えてるんだ。 やっぱり複雑過ぎるものは駄目だからね(と、設計を黒板に書きはじめる)。

他にもいろいろと話したような気がするのだが、忘れてしまった。もったいない。 録音でもしておくべきだったか。大半はアメリカ、日本、デンマーク、トルコ(Salih教授の出身地)の 文化・慣習の違いについてとかだったような気がするけど。

しかし、Bjarneはえらく頭が良くて、しかも(私の視点から見ても)言語設計に対して「正しい思想」を 持っているようなのに、C++がえらくアレなのはいったいどういうことだろうか。 やはりC++が志向する領域が本質的に複雑で、その複雑な状況に対応するためには言語も複雑にならざるをえなかったということなのだろうか。 もちろんC++の問題の本質は使い方によるのであるが、そういう使い方ができてしまうのも問題といえば問題なのだが。

The Design and Evolution of C++を(サイン入りで)いただいたので、 ちょっと研究してみることにしよう。

夕方からは今回の招待のメイン、招待セミナー。 今回のスライドはここ。 下手な英語ではあったが、そんなに悪い話はしなかったと思うけど、あんまり盛り上がらなかったなあ。

その後、Austinに移動。運転手は昨日と同じ女性だ。今夜は1時間半ほどで到着。 やっぱり途中は寝ていた。乗り物に乗るとすぐ寝ちゃうなあ。

ホテルでRich Kilmer、Chad Fowler、David Alan Blackたちに会う。 少しおしゃべりしてから部屋へ。

で、部屋でLinux Magazineの原稿を書くのであった。

追記:

ツッコミをいただいたので返事しておく。

まず、KLさん。Rubyについて聞かなかったのは、 彼がRubyについて名前以外なんにも知らなかったからです。 私がセミナーで説明した後ではある程度分かって「面白い」と言ってくれましたが、 その後すぐ別れちゃったし。つっこんで聞く機会はありませんでした。

次に、とおりすがりさん。 「私がJavaが嫌いだからBjarneからネガティブな発言を引き出したがっている」という推理は 当たっていないように思います。だって嫌いじゃないもん。 興味が持てないだけで。たぶんBjarneも同じ意見だと思います。

本日のツッコミ(全8件) [ツッコミを入れる]

_ とおりすがり [http://hp.vector.co.jp/authors/VA000092/jokes/strup.html と..]

_ y [http://www.research.att.com/~bs/bs_faq.html#IEEE Of cours..]

_ KL [Javaはともかくとして「Rubyについてどう思うか」という話題への到達は必至ではなかったかと思うのですがどうでしょ..]

_ とおりすがり [なんで「Javaについてどうか」って質問するんでしょうか? 個人的には、まつもと氏がJavaを嫌い(?)なのを自分の..]

_ とおりすがり2 [自他共に認める日本の言語オタクが、現在これほど広く使われている言語に対して「興味がもてない」としらっと言ってしまうと..]

_ まつもと [「好きじゃない」と「嫌い」の区別をしない言語感覚の人にとってはそうなんでしょうね。私自身は「嫌いな言語」という言葉は..]

_ AC [嫌いな言語リストと好きな言語リストをどっかに書いておけば解決する話でしょ。 言語オタクだからと言って自然言語も堪能と..]

_ 村田拓哉 [教授のホームページになぜ、言語の比較をしないのか書いてあります。 http://www.research.att.c..]

[]

2004-11-13

_ [家族]息子の自転車

小学校1年生の息子は最近まで自転車にさっぱり興味がなかったのだが、 とうとう自転車に乗ることを覚える気になったらしい。

「やる気になった時にやらせる」のはうちの教育方針なので、 さっそく自転車を買いに行くことにする。 自分で自分の自転車を決めることそのものが、 脳味噌の普段使っていない部分を刺激するらしく、頭から煙が出そうなくらい悩んでいた。

あちこちの店を回ってさんざん悩んだ揚げ句、 BMX風の22インチ車を購入することにした。普通、もうちょっと子供っぽいのにするんじゃないのか。

まあ、いいか。

[]

2005-11-13

_ [教会] 監督不在

司会。あまりうわずらなくなってきた。

副監督の一人は岡山、監督も聖餐会終了後は監督訓練集会で岡山。 取り残された私は少々不安だったが、とくになにごともなく終了。

集会終了後、面接。いろいろと懸念事項を聞く。 教会といえどもいろんな人の集まりなので、 心配事やら、問題やらいろいろあるものだ。

依頼されたことは手配しておく。

[]

2006-11-13

_ バッテリー復活

結局、以前よくお世話になってた整備工場に電話して来てもらう。 わざわざ出向いてもらって、交換までお願いしたのに、 バッテリーの代金だけで済ませてもらった。

ありがたい。

_ [原稿] 日経Linux 2007年1月号

「オープンクラス」完了。疲れた。

_ 緊急持ち出し

家庭の夕べで緊急持ち出しカバンの中身をチェック。

前回チェックしてから数ヶ月にしかならないのに、 虫がついてたり、消費期限が過ぎたりで、だめになってるものがあったり。 なかなかメンテナンスが面倒なものだ。

_ Colemak keyboard layout: ergonomic, fast and easy to learn QWERTY/Dvorak alternative

QWERTYに似てるけど、ずっと良いキー配列。

  • QWERTYからの変化が少ない
  • Dvorakより移行が簡単
  • 効率はDvorakと同等

なんだそうだ。具体的には以下のようになってる。

TAB Q W F P G J L U Y ; [ ] \
 BS  A R S T D H N E I O '
SHIFT Z X C V B K M , . /

個人的には大量に文書を入力する日本語に対して「きゅうり改」があるから、 そんなに魅力的ではないけど、英文をたくさん入力する人には効果的、かも。

本日のツッコミ(全2件) [ツッコミを入れる]

_ eisuu-kana [日本語用には、きゅうり改以降も多くのキー配列が提案されていますよ。 英文用に最適化されたものは、和文用にはやはり少し..]

_ MMX [英字最適では UK が低頻度扱いで、ローマ字には最適になりません。右手のキーが右手のままで移行しやすそう。 back..]

[]

2009-11-13

_ [言語] The Go Programming Language

もう知っている人は知っているGoogleからのシステムプログラミング新言語Go。

すっかり祭りには乗り遅れた感があるけど、少しだけコメントをつけておこう。

目次

  • 言語仕様
  • 言語実装
  • 技術的でない話
  • まとめ

言語仕様

総合的に見て、非常にバランスを考えているように思える。 JavaやC++のような複雑さを排して、シンプルに徹する一方、 言語好きを刺激するような新しいアイディアをそこかしこに配置している。

特徴である「コンパイルが高速」というのも、 このシンプルな言語仕様が寄与していると思われる。

個人的に、注目したのはオブジェクト指向機能と、並列機能。

interfaceによる、継承のないオブジェクト指向(duck typing)は、かなり私好みである。 昔からこういう言語が欲しかった。interfaceのみ動的結合を許すというのも Satherを思い起こさせて好印象。

ただし、私が見た範囲内では、実装の継承(共有)は提供されないみたいなので、 Javaのinterface同様、コンポジションを強制されることになるので、 そこは残念。

それから、goroutineなる並列実行機能。 Erlangを意識してるのかな。でも、それ以上に使いやすそうな印象。

go 式

だけで並列実行が開始できるのは大胆である。 ほとんどのオブジェクトが値渡し(コピーされる)とあいまって、 効率よく並列実行できそう。

あと、多値を活用しているもの面白い。 成功したかどうかを2番目の値で返すところとかもErlangを思い起こさせる。

「逆転した型宣言」は、はじめはギョッとしたけど、 慣れたら結構良いかもしれない。

言語実装

コマンド名! 8cとかなんだよって感じ。

ソースコードを眺めたが、正直、一番興味があるランタイムの部分は よくわからなかった。だいぶ慣れないとなにがどこにあるのかよくわからない。

GCはシンプルなマーク・スイープだった。

goroutineのsegmented stackの実装に興味があったのだが、 まだみつからず。たぶん、そこはランタイムじゃなくて、 コンパイラそのものを見ないとわかんないんだろうな。

技術的でない話

「Goが登場したからには(Java/C++/Python)はお払い箱」みたいな エントリをいくつか見かけたけど、まだまだそういうレベルではないと思う。

Goは非常に興味深い言語だし、当面いろいろと話題を提供してくれるとは思うけど、 これが定着するか、成功した言語になるかどうかは、長い目で見ないとわからないと思う。

GoogleやRob PikeやKen Thompsonのネームバリューのおかげで、 普通なら10年かかるプログラミング言語のブランド確立を一瞬で達成してしまった Goだけど、成熟度としてはまだまだなので、当分はそのギャップに苦しむ(?)ことに なるんじゃないかな。

そこを乗り越えて、「一人前の言語」になっていくことを期待したい。

まとめ

  • 言語の成功は長い目で見よう
  • Goガンバレ(えらそう)
本日のツッコミ(全30件) [ツッコミを入れる]

Before...

_ とおりすがり [ええ、捏造は言いすぎたと反省してます。 撤回します。]

_ roverhand [とおりすがりさんは、言いすぎかどうかという前に、勘違いしてるのではないかと思うのです。 お払い箱論調に対して「..]

_  [なうってなんだよ。 にょと変わらんな。キモ。]

_ とおりすがり [勘違いではありません。 否定的な情報を並べて達観するのはH○Kが良くやるプロパガンダの手法です。N○K自体は否定し..]

_ 加藤和良 [まつもとさんが読まれたのは、ここからリンクされているスレッドではないでしょうか。 http://news.ycom..]

_ hnakamur [加藤和良さんが紹介されたスレッドに http://code.google.com/p/unladen-swallo..]

_ まつもと ゆきひろ [加藤和良さん、 ありがとうございます。私の記憶と一致します。 そうか、Hacker Newsか。 複数提示する..]

_ kyon [以前、Pascalっぽくないとコメントしてしまったのですが、今はGoは、けっこうPascalっぽいと思ってます。すみ..]

_ ま。 [こんなページもありました。 Ciao Python, Hola Go! http://tav.espians.c..]

_ KL1 [Goで思い出したのですが、KL1ってどうなったんでしょうか? http://www37.atwiki.jp/pro..]

[]

2010-11-13

_ [Ruby] RubyConf 2010 キーノート(2)

前回に続いて 未来(≒Ruby 2.0)の話を。

今回、紹介した「未来」の機能は以下の通り。

  • Traits
  • Method Combination
  • Keyword arguments
  • Namespaces

今まで話してきたことじゃん、と思うでしょうが、その通り。 違いは

  • これらの機能が単なるアイディアではなく、どのように実装すべきかほぼ見えている
  • 実装した機能を突っ込む場所(trunk)が明確になっている

点です。特に後者は大きい。

Traits

Traitsの定義は

a trait is a collection of methods, used as a "simple conceptual model for structuring object oriented programs".

from Wikipedia (en)

ということで、モジュールとほぼ同じようなものです。 実際、今回導入するTraitsは言語要素の実体としてはモジュールを利用します。

ただ、モジュールの機能を取り込むのにincludeではない 別のやり方(mix)を導入することによって、includeが持ついくつかの問題を解消しよう というものです。includeの方が便利なこともあるので、includeもなくなりません。

includeの問題は

  • 名前の重複を検出できないこと
  • モジュールのinclude関係が後から変化した場合の一貫性のない挙動
  • メソッドを後から修飾する(wrapする)方法が提供されない

ことです。

擬似的な多重継承であるincludeは、 includeされたモジュールが継承ライン(ancestors)に含まれるようになります。 この時、状況によっては予測困難なことが発生します。

ひとつはincludeされた複数のモジュールで同名のメソッドが定義されていた場合、 その重複が意図されたもの(override)か、偶然か(conflict)か、 区別する手段がないところです(名称重複問題)。

もうひとつは、いくつかの状況で継承ラインに並ぶモジュールの順序が予測しがたい (ので、メソッド名の重複時にどれが優先になるのか直感的でない)ことです。

module American
  attr_accessor :address
end
module Japanese
  attr_accessor :address
end
class JapaneseAmerican
  include American
  include Japanese
end
JapaneseAmerican.new.address
# which address?
p JapaneseAmerican.ancestors
# => [JapaneseAmerican, Japanese, American, Object, Kernel]

この例ではaddressという属性(メソッド)がAmericanとJapaneseの間で 重複していますが、これが意図的な重複なのか偶然かは言語にはわかりません。 継承ラインの順にしたがってメソッドを呼び出すだけです。

実際にはJapaneseモジュールが優先されてそのaddressメソッドが呼ばれるのですが、 ひとめでそれが分かるのは、だいぶ「訓練されたRubyist」です。

現在のRubyでは、includeされた時、 「スーパークラスですでにそのモジュールがincludeされていた時には 二重にincludeしない」という挙動になっています*1。ですから、 スーパークラスでincludeされていることに気がつかなかった場合、 includeしても継承ラインのその場所にモジュールが登場しなかった ということが起こりえます。

それから、モジュールが既にincludeされてから、 そのモジュールに対してincludeを行った場合、 既に存在するクラスの継承ラインには新たにincludeされるようになったモジュールは含まれません。 つまり、includeのタイミングによって継承ラインへの反映のされ方が異なるわけです。 ちょっと気持ち悪いです。

これらを(ある程度)解決する手段がmixメソッドです。

mixメソッドをincludeの代わりに使うと、

  • 現在モジュールに定義されているメソッドを クラス/モジュールに注入する
  • mixされたモジュールは継承ラインに登場しない
  • メソッド名の重複は例外になる
  • 例外がイヤならモジュールを書き換える、 または重複したメソッドの名称を変更する
  • 定数を取り込むかどうかを指定できる。 デフォルトは取り込まない

という振舞いになります。これにより

  • 名称の重複はエラーになるので、見逃しがない
  • 名称変更ができるので、明示的に解消できる
  • あくまでも「現時点での状態の注入」なので、 継承ラインが変化した時の「おかしさ」がない。 問題は解決していないが、気分は良い(苦笑)

ということが実現できます。

たとえば以下のようなコードでは

module American
  attr_accessor :address
end
module Japanese
  attr_accessor :address
end
class JapaneseAmerican
  mix American
  mix Japanese  # => address conflict!
end

addressメソッドが重なっているからmixできません。 無事mixさせるためには名称衝突を明示的に回避します。

class JapaneseAmerican
  mix American, :address => :us_address
  mix Japanese, :address => :jp_address
end

これで、addressという名前による重複はなくなりました。

なぜ、includeにオプションをつけるのではなく、 新しいメソッドを導入して言語をより複雑にするかというと、 個人的にmixの挙動の方が望ましいと思っていて、 ユーザーをそちらに誘導するためには、より短い名前の方が望ましいと思ったからです。

Traitsを実現するmixメソッドの実装ですが、 RubyKaigiでこれを紹介したその日には中田さんが着手していて、 パッチは完成しているそうです。

ただ、各種プレゼンテーションでは説明しなかった以下の課題があり、 これらについては結論を出す必要があります。

  • mixされるモジュールが別のモジュールをincludeしていた場合にはどうなるか。 おそらくは例外になる。mixとincludeは混ぜるべきではない。
  • mixで別名を付けて問題解決、と読めるような言い方をしているが、 実際にはモジュール内部で名前を書き換える前のメソッドを読んでいる可能性がある。 それをどうするか。なにもしない(重複する方が悪い)とする考えもあるが、 それだとせっかく苦労してTraitsを導入しようとしているのが まったく無駄になるので、名前を書き換えたメソッド呼び出しを モジュールのメソッド定義実体から探し出してメソッドをコピーする という(Bertrand MayerのOOSCに記述されていたアイディア)を導入することを考える
  • インスタンス変数の名称重複を解決する手段がない。 これはサブクラスからは見えないインスタンス変数を導入し、 mix対象のクラスではそちらを使うこと推奨とするべきではないかと 考えています。1.9向けのパッチは既に書いてありますが、 プライベートなインスタンス変数の記法を @_fooをにするか、@__fooにするか、 はたまたまったく違うナニかを考えるのかが難しくて現状では放置されています。 mixが導入されたらより必要になるでしょうね。

Method Combination

RubyKaigiではmixの一部として導入する話をしていたMethod Combinationだが、 mixでいちいち「どのメソッドをラップするか」とか指定するのが以上にめんどくさいことに 後で気がつきました。ので、分離。

今回の案はprependというメソッドを導入すること。「include、mixに続いて またもうひとつ?」という声が聞こえてきそうだが、私もそう思います。でも必要なのよ。

prependはそのモジュールが提供する機能を、現在のクラス/モジュールの「前」に 追加する機能。

module Foo
  def foo
    p :before
    super
    p :after
  end
end
class Bar
  def foo
    p :foo
  end
  prepend Foo
end
Bar.new.foo # :before, :foo, :after

とように使う。prependしたモジュールFooで定義されたfooメソッドが、 prepend先のメソッドfooをラップしているのが分かるでしょうか。

prependメソッドは、RailsコミッタでもあるYehuda Katzの提案で、 これがあればRailsのalias_method_chainを撲滅できる、と息巻いていた。 私もそう思う。

具体的な実装はまだないんだけど、たぶんT_ICLASSのようなものを 継承チェーンに置いて、そっちを先に検索するようにするんじゃないかなあ。

Keyword Arguments

引数、特にオプショナル引数がどんな働きをするのか忘れる人は私だけじゃないと思います。 たとえば、 public_instance_methods メソッドはオプショナル引数を受け付けるのだけど、 それが「オプショナル引数を付けると、それが真であった時にスーパークラスのメソッドを含む」のか、 それとも逆かというのは私でもいつも忘れてしまいます。正解はfalseを付けた時に含まない。

これをたとえば

aClass.public_instance_methods(include_super: false)

と書けたら、ずっと覚えやすくなるというものです。

Rubyのキーワード引数は、1.9で追加されたシンボル記法のハッシュが 引数リストの末尾に付いているだけです。

2.0で新たに追加されたのは、メソッド定義側でこれを簡単に受け取れる記法です。

例としてはこんな感じ。

呼び出し側

1.step(by: 2, to: 20) do |i|
  p i
end

呼び出され側

def step(by: step, to: limit)
  ...
end

後、「**」で辞書形式で受けとるとか、ちょっとした機能追加もありますが、 基本的にはこれだけ。

Namespace

技術的な詳細などについては同じRubyConfで前田(修吾)くんが発表したスライドを見てもらった方が良いと思います。

Rubyではopen classといって既存のクラスの定義を書き換えちゃうことができる。 メソッドの追加も自由自在だ。このように既存のクラスに「パッチ」を当てちゃう技法のことを 「Monkey Patching」と呼ぶことも多い。

これは「ゲリラ・パッチング」→「ゴリラ・パッチング」→「モンキー・パッチング」と 変化して生まれた用語なんだって。 まあ、Rubyはクラスなんてものは変化するもんじゃないって「硬い」言語よりも 大きな自由を提供してることは確かだよね。 DHHは今回のRubyConfのキーノートで「今後はMonkey PatchingじゃなくてFreedom Patchingと呼ぼう」と 叫んでた。メル・ギブソンの『ブレーヴハート』を引用しつつ。「ふりーだーーむ」。

まあ、フリーダムなのは素晴らしいことなんだけど、影響力が大きすぎるというのもまた事実。 やろうと思えば整数のプラスメソッドを書き換えて、1+2 = 42 のような変更だってできちゃうから。 でも、大抵のプログラムは副作用でまともに動作しなくなるよね。

で、問題はこのような変更の影響の範囲がグローバル(プログラム全体)であることで、 仮にこのような修正をなんらかの「スコープ」に閉じ込めることができたなら、 もっと安全に、もっと安心して「フリーダム・パッチング」を活用できる、はず。

そのような「スコープ」のために、昔からClassboxとかSelector Namespaceとかが提案されてきた のですが、今回、前田くんが実装したのはSelector Namespaceの一種であるRefinment。

たとえば、以下のようなプログラムがあったとします。っていうか、あります。

class Integer
  def /(other)
    return quo(other)
  end
end
p 1/2 # => (1/2)

これは割り算演算子(/)を再定義して、整除ではなく結果を有理数にしようもので、 標準添付ライブラリの mathn の本質部分です。 しかし、整数の割り算の結果が整数であることを期待しているコードは当然存在するわけで、 そのようなコードは上のような変更で破綻する可能性があります。

そこで今回導入しようというのがrefinmentです(呼び名は変わるかもしれません)。 文法としては以下のようになります。

module MathN
  refine Integer do
    def /(other)
      return quo(other)
    end
  end
  p 1/2 # => (1/2)
end
p 1/2   # => 0

Refinementの単位としてはモジュールを使います。またモジュールです。大活躍ですね。

モジュールの中では既存のクラスをrefineできます。 refineの中で定義された修正はそのrefinment(ネームスペース)の中でだけ有効です。 ですから、MathNモジュールの中では 1/2 は有理数の (1/2) であり、 その外側では今まで通り整除になっています。有効範囲はレキシカルであり、 Refinmentはブロックの外側には影響を与えません。

Classboxとの違いは、そこを通じて呼び出された先(レキシカルスコープの外)に 「置き換え」が影響を与えるかで、いろいろ検討した結果、 多くのプログラミング言語がダイナミックスコープをあきらめたのと同様の理由で 「置き換え」はレキシカルになるべきだとの結論を出しました。

モジュールとして実現されたネームスペースを使うには usingメソッドを使います。 こんな感じ。

module Rationalize
  using MathN
  p 1/2 # => (1/2)
end
p 1/2 # => 0

これでRationalizeモジュールの中ではMathNが提供するRefinementが利用できます。

さらに、今までメソッドの中でメソッドをネストして定義した場合、 そのメソッドはクラスに直接定義されてあんまり意味ないじゃん、みたいな状態になっていたのですが、 今後はそのメソッドの範囲内でだけ有効なRefinementにネストの内側のメソッドが定義されるので、 完全にプライベートなメソッドとして使うことができます。

class Foo
   def foo
      def bar
        ...
      end
      bar # 呼べる
   end

   def quux
     bar  # 呼べない
   end
end

この変更はかなり大規模かつ複雑なものですが、前田くんのところでは実際に動作しています。 早く trunk に突っ込みたいものです。しかし、NaCl取締役の激務をこなしつつ、 こんなスーパーなパッチを作っちゃう前田くんに拍手。

まとめ

歴史編で見てきた通り、ずっと昔からキーワード引数などについて話してきましたが、 とうとう現実になりそうです。長かった。

*1  MacRubyでは違うらしい。Ruby 1.9でそのような変更をしたかったが、YARVが継承ラインに同じモジュールが2度登場しないことを前提にしていたため断念

[]

«前の日(11-12) 最新 次の日(11-14)» 追記

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.