rails 的 console 實作 (2)

Got a few requests for the detail (詳細希望？)
一個在 buzz 上面，就是上篇自動轉到 buzz 的那篇。
另一個是上篇的 comments

先貼上寫在 buzz 上關於 optparse 的想法：

不用 optparse 其實現在已經沒有很強的理由了 orz
原本不用的原因是，我不希望修改 ARGV, 希望 ARGV
保持原本的狀態。另一方面，這 Runner 還是由 ripl
那邊改來的，他原本也沒有用 optparse, 基於什麼理由我就不清楚了

但是後來由於要實作 rib-rails, 導致不修改 ARGV 會變得不好做
於是我也開始修改 ARGV 了。既然都改了 ARGV, 那似乎就沒有
強烈不用 optparse 的理由了.. 但既然都寫好了，似乎也沒啥理由
再換成 optparse.

那個修改不修改 ARGV 的差別在，要讓 rib-rails 和 rib rails 以一致的
方式運作的話，勢必得修改 ARGV. 也就是說，在 rib-rails 裡可以直接
使用 ARGV, 而在 rib rails 裡則把 rails 這個值幹掉，使得兩者用一致的
方式去看 ARGV. 這樣所有的 bin 都可以直接使用 Runner.

另外，我不太清楚 optparse 可以支援 --abc=def 和 --abc def 和 -wvI 嗎？

然後剛剛 released 的 0.9.5.pre.1 支援上篇提到不支援的用法了。
rib -wdIlib
等同於
rib -w -d -I lib
等同於
rib -w -d -Ilib
等同於
rib -wd -I=lib
一般常見的用法都可以用，挑自己喜歡或是習慣的用即可 :P

ok, 接下來我們來看 rails console... 看法是從 rails 2 開始看，
然後看看 rails 3.1 有沒有改進。

* rails 2 是用 exec 去跑 $PATH 中的 irb, 假設我現在想用 jruby
跑 ./script/console, 如果我用 jruby ./script/console 去跑的話，
基本上因為他還是去讀 irb, 所以會完全沒效果。取而代之， rails 2
提供了 --irb 的選項，可以讓我換別的 irb 去讀。所以如果我有
jirb 的話，大概就可以跑 ./script/console --irb jirb 吧... 但是如果
沒有 jirb, 平常都是用 jruby -S irb 去跑的話，那只能恭喜我沒救了。

這點總算在 rails 3.1 有所改進，總算是直接從原本的 process 直接
讀出 irb 然後跑起來。因此 jruby -S rails console 有效了，可喜可賀。

* rails 2 有一大堆檔案全部都沒有 prefix. 比方說 console_app.rb,
console_with_helpers.rb, 都是直接放在 $LOAD_PATH 裡面。
我以為用個 prefix 是常識。如果跑 require 'commands' 實際上會
require 到 rails 2 的程式。還有很多類似的... 總算 rails 3.1 不再
做這種蠢事了。

* rails 2 把所有的 commands 都寫在 top level, 沒有在任何 module
底下。這個.. 除了 quick and dirty 外我想不太到該下什麼評論，也懶得
多說為什麼這樣不好了。rails 3.1 有改進，不過沒完全改善這個部份。

* interface 不一致。為什麼 server 是 rails server -e production 但
console 卻是 rails console production 呢？在 rails 2 是
./script/server -e production 和 ./script/console production.
還是一樣不一致。不過對 rails 2 -> rails 3 這點來看的話，倒是一致。

仔細想想，大概就以上四點比較重要吧。其中 rails 3 算是改進了兩個半。
簡單地說，rails 很多的程式，我覺得都寫得很草莽。或是說沒有整體的
設計，完全是用一堆 patch 疊起來的東西。其中 rails 2 還有 RAILS_ENV
這莫名其妙的東西... 跟 ENV['RAILS_ENV'] 和 Rails.env 還不一樣？

大概先這樣吧。