NETRuby

NETRuby(これは総称。実際のクラス名はNetRuby)は、RubyをC#で再記述する試みだ。

心境の変化

以前、次の公式を書いていた。 Java : JavaScript = Ruby : NETRuby 要するに、NETRubyは、Rubyに似ているが全くの別物である、と。
Javaには、JDKがある。JavaScriptにはそんなものは無く、ホスト環境のオブジェクトモデルがあるだけだ。
NETRubyは、.NET Frameworkを操作するためのRubyモドキ(=Javaに対するJavaモドキのJavaScript)という位置付けだ。

ASRの理由

Win32には、ろくな簡易言語が無いと言うのがActiveScriptRubyの開発動機だ。 VBScriptもJScriptも有体に言えば機能不足だが、かと言って、いちいちC++やJavaでちょろっと書くのは馬鹿げている。コンパイラを通すわけだから、その分手間がかかるし、ちょこちょこ変えながら処理させていくというスタイルには合わない。そもそも「ちょろっ」とUIを書くのは面倒だ。
だが、インフラとしてIEが存在するわけだから、まともな言語のActiveScriptブリッジがあれば、それでOKじゃないか。C++やJavaを使う必要は無いわけだ。
ここで、僕はPerlもPythonも触ったことが無かったということが、ASRにつながっていく。同一スタートラインから、Perl、Python、Rubyを見れば、オブジェクトが操作のベースにあるという一点だけで、Rubyが勝利したわけだ(まあ、途中でHaskelとかも見たり(全然、この文脈とは関係ない言語だが、未知なものには興味があるし)、Forthのサンプル実装(があるし、軽いから拡張しやすそうだったし)に傾いたこともあるんだけど、日本語ドキュメントがある3大スクリプト言語の一つってのがやっぱり大きかったのかも)。

新たな環境の出現

そこに、.NETだ。で、同様な理由から、NETRubyにつながっていくわけだ。ここでは、実はコンパイルは問題では無い(矛盾してるように見えるかも知れないが、一番重要なのはリフレクションの操作だったりするから、「その言語を使って実現したいこと」が、Win32の場合とは異なってるのだ)。
その試みがここにあった。
が、やめた。というのは、この目的にはC#で十分だからだ。要するにC#はすごく気に入った。

わかっていること

なお、ハロウィン文書は熟読してるから、当然、CLRが撒き餌ってことは先刻承知だ。Monoの連中のことは知らんが、僕は、いわゆるMS的なバータリーで、目先の変ったアプローチが好きなんだよ。
だから、基本的にバータリーなのさ。っていうか、リアルワールドとは正反対のアプローチを取れるってのが楽しいのかも知れないな。

現在の方向

そもそも、NETRubyをRubyモドキにしようとしていた大きな理由がある。Enumerate わけだから、クソマジメにポーティングしたくは無いと感じるのは当然だ。

愚公山を移す

おやおや、JRubyとか作ってるよ。つーか、やればできるじゃん? あっちは、4人がかりみたいだけど、僕の生産性は少なく見積もっても5人分だから(当社比。言うだけならタダだよな)、どうにかなるんじゃないか? ―― もちろん、ここはバカな考えだった。リアルワールドでの生産性を真夜中の油に当てはめちゃいかんよね。
なお、JRubyはソースが分割され過ぎているし、コーディングスタイルがJava過ぎて読む気になれないから、ほとんどというかまったく参考にしてないわけなんだが。
もちろん、JRubyが存在するからといって、最初に挙げた理由は消えていない。しかし、考えて見たら、もともとのNETRubyがRubyモドキだと宣言しているわけなんだから、1.6モドキということで折り合いが付いてたり。
あと、非常に大きな理由として、Monoの連中がJayのC#対応修正を完了させていたってのがある。
個人的に本家の仕様変更が気になるのは、何よりパーサのポートが重荷だったからだ(細かなクラスの動作の差は大して気にしてない。そもそも、StringをUnicodeベースにするって決定しているわけだから、100%互換になるはずが無い)。
ここが、parse.cからのポートをするのか、parse.yからのポートで済むのかってのは、作業量的には非常に違うからだ。
っていうわけで、NETRubyは、Java:JavaScriptから、Ruby:JRubyの線で行くことにしたのであった。

NETRubyの理由

T.B.D

実装

オブジェクト

これだ。まだ、四則演算くらいしかできないけど。
JayのC#ポートが無くてもメークできるように、生成後のC#ソースも同梱してある。
ソースの解説
ファイル名オリジナル備考
NetRuby.cseval.c+ruby.cってとこメイン。巨大クラス
nrb.csmain.c相当
Kernel.cssprintf.c+object.csprintfマンセー(いい加減だけど)
Object.csobject.c + ruby.hうーん……
Class.csclass.cここ好き
Node.cseval.c相当充実してきた
Scanner.cslex.c + parse.yそのまんま
Parser.csparse.cMonoの連中のエフォートに感謝
parse.yparse.yそのまんま
Numeric.csnumeric.c仮想関数の恩恵
Bignum.csbignum.cムズイ……
excep.cserror.c迷いがある。.NET Frameworkのクラスを使うほうが正しいのでは無いか?
Const.csobject.cなどシングルトンで即値代わり
Symbol.csruby.h object.cなど相当無理がある
frmobj.cswin32ole.cこれが無きゃね。
Array.csarray.cArrayListラッパ
String.csstring.cStringラッパ?
Proc.cseval.cProc
Thread.cseval.cThread関連
Time.cstime.c.NET Frameworkはtime_tじゃないから面倒だ
Enum.csenum.cEnumerable
Regexp.csre.cRegexラッパ
Hash.cshash.cHashtableラッパ
Loader.cseval.crequireとかの処理
io.csio.c3/10開始
MakefileMakefile.subとかnmake 7
やっぱり、小迫さんはすごい。としみじみ思う。
.NET Framework SDKがあれば、メークできる。英語版のリリースでも、日本語Windows2000SP2+IE5.5SP2UPにインストールし、動作している。

サンプル

一応、VB.NETとC#の組み込みサンプルも同梱してある。Netruby.dllに対してLIBPATH通すか、Netruby.dllと同一ディレクトリでコンパイル可能。
英語ページにも書いたが、現時点で将来までAPI互換性を保証できるのは、NetRubyクラス、NetRubyクラスの無引数コンストラクタ、Init()メソッド、EvalString()メソッド、Funcall()メソッドだけ。
また、現時点のNetRubyのインスタンスはスレッドセーフでは無い。
以前の試み
Last modified: Sun Mar 10 22:36:13 LMT 2002
GeoCities Japan

戻る
copyright(c) 2002 arton, Under GPL