http://www.tokyo-nazo.net/%7etester/kako/best.html#20031015
10 月は HDD が一番壊れやすい月なんだってさ。へー。
(08:15)
Ripper::Tokenizer はやめて Ripper::Filter というクラスを作った。
特徴
……まあようするに、 うささんとこの色付けスクリプトみたいのを作るために特化したクラスです。
require 'ripper/filter' class ColorizeFilter < Ripper::Filter def on__default(event, tok, out) out << tok end def on__tstring_content(tok, out) out << %Q[<span class="string">#{tok}</span>] end def on__comment(tok, out) out << %Q[<span class="comment">#{tok}</span>] end # 以下略 end result = ColorizeFilter.new(ARGF).parse('')
と、こんなふうに書ける! これはいいなあ。
こう考えてみると、実は on__scan っていらないんじゃないだろうか。
というか、on__ じゃなくて on_ でいいんじゃないだろうか (orz じゃないよ)。
(08:53)
だんだん考えがまとまってきた。 Ruby プログラムをテキストとして扱いたい人たちには Ripper::Filter があればほぼ十分だろう。 あと必要なのは一発で構文木を作るインターフェイスと、 構文木自体を自分で作りたい人向けのインターフェイスだな。 で、前者は誰ぞが作ってくれたやつがあるので、それを持ってくればよい。 後者は Ripper クラスを直に使ってもらえばいいだろう。
もともと on__scan は Ripper::Filter みたいな用途のために付けたわけだが、 定数 SCANNER_EVENTS を付けたことで必要なくなったと考えていい。 on__scan は semantic value の扱いに関してもうまくないので邪魔だ。 やはり on__scan は捨てよう。
on__ のほうはちょっと迷うけど……。 うーん、どうしようかな。on_ でいいかなあ。 誰か決めてー!
(09:09)
ちなみになんで on_ じゃなくて on__ かと言うと、 「Ripperは継承しないといけないし on_ だと他のモジュールのメソッドと重なりそうだよなー」 という程度の理由しかなかったりする。
(09:13)
どさくさに紛れて setup.rb をアップデートしてみた。 評判の悪い config setup install をついにあきらめて
$ ruby setup.rb
で全部やるようにした。 もちろん元の config setup install でもできるので 細かく制御したければそっちを使ってください。
ついでに
$ ruby setup.rb all --prefix=$HOME
なんてのもできるようにした。
(12:16)
http://mono.kmc.gr.jp/~oxy/w/hiki.cgi?ast
そうか、「AST」というライブラリが別にあったんですね。失礼しました。 昨日のぼくの発言は一般名詞の「AST (Abstract Syntax Tree)」のことでした。 Ripper はしばらく RubyForge に入っていたんですが、 そこの lib/ripper にも ast.rb があるんです。
んでこいつの作りがいまいち好きになれない。 特にライブラリとしての名前付け規則に従ってないのがよろしくない。 ファイルが ripper/ast.rb でメインクラス名が Parse::Tree で その他に module Ruby が定義されていて、 一方実際に構文木を作るのは ripper/genast.rb になってる。 もうちょっと整理してほしいんだけどなあ。
(12:22)
Copyright (c) 2002-2007 青木峰郎 / Minero Aoki. All rights reserved.
ripper って,パース時の環境ってどう扱ってるんですか? ローカル変数とか.
parse.y を FIXME で grep するとよいことがありそうです
こわくて checkout 出来ないのです(ぉ
なるほど。ripperの中にast.rbが有ったんですね。昨日は早とちりをしてしまったみたいで、こちらこそすいませんでした。