著作一覧 |
あるクラスが他のクラスと等しいかどう判断するか?
jclass jc1 = (*jenv)->FindClass(jenv, "foo/bar/Baz");
で得たクラスの参照は、次の機会に
jclass jc2 = (*jenv)->FindClass(jenv, "foo/bar/Baz");
とやったり、
jclass jc2 = (*jenv)->GetObjectClass(jenv, obj);
とやったものとは異なる参照となる。ほぼ100発100中。
したがって、jc1 == jc2という比較はできない。つまり参照の先を見なければならない。
このためには、jni.h上の定義ではjclassとjobjectというように異なる型とされているが
jboolean IsSameObject(JNIEnv *env, jobject ref1, jobject ref2);
を利用する。jobject ⊃ jclass 。jclassはjava.lang.Classのインスタンスなので(追記:これは間違いだな。Javaのリフレクションにとってのクラスの型であるjava.lang.Classとは異なるJNIにとってのクラスの型の何かがあって、jclassはそれのインスタンスだからjava.lang.Classのインスタンスとは異なるものだ)したがってjobjectでもある。
これは、JNI Functionsを見てもわかりにくい。
iPodのおかげで忘却の彼方から引っ張り出されてきた。
赤ちゃんが燃えている。そら、水をかけろ。(嘘訳)
写真立てにはきりりとした良い男のイーノ、でも鏡には朝寝坊した年増のあいまい宿の女将みたいなイーノ。
伊能輝彦っていう日本語名をかってにつけたのを思い出してみたり。
きたー
kshとRubyを比較して、Rubyを使うとこんなにいいことありますよ、ってのをまさかおいらが書くことになるなんて、予想もしてなかったよ(自分の手だけでは決められないとこだし)。
・Win32でも各種Unix(Linux含む)でも、基本的には共通のプログラムが利用できる(Win32でkshを使うには、SFUの導入が必須かつすべてが利用できるわけではない)
→うちはWin32使いませんからな、といわれると弱いね。
・スクリプトとしての生産性が高い
#これ、事実だと思うけど([]の中の空白の置き方次第でエラーになる言語とは比べてはいかんだろう)数値化できないよね。
・開発時に覚えること(調べること)が少なくてすむ(学習曲線がなだらかと言うんだっけ)
#これ、kshですべてまかなえるはずはありえないから、まともに使うにはkshだけではなく各種コマンド(sort、grep、catあたりからsedとかawkとかまで含む)にも通暁する必要があるのに対して、RubyならRubyと一部拡張ライブラリまででまかなえるという意味なんだが、このへんってわからない人にはわからないのはUnixの各種コマンド自体というか仕組みを知らなくてkshってのがプログラミング言語だと勘違いしているということなんだろうか?
#こういったことをあまり言い出すと、Cで開発すれば良いというとんでもない方向へ話が進む可能性があったり。
・おいら、サポートできるんですけど。でもksh(+コマンド群)はソースが無いからベンダーのサポートに問い合わせなければだめですな。だから、問題が発生した場合の解決までのターンアラウンドはRubyのほうが早いですよ。
#coreになります、な使い方するわけないし、その範囲ではね。とは言え、それこそ属人性というやつでそんなことを言えるはずがない。
なんか、ガツンとした理由ってないかな? 助けて紅い人!
ちなみに、Perl,Pyあたりはどうよ? ってのは有り得ないので考慮不要。USL正統のシェルスクリプトとそれ以外という比較であり、それ以外についてはpyな人やPerlな人はいないので。
#DBIの存在ってのはあるな。シェルスクリプトならRjbもある(っていうかそのための準備でもあったりして)し。とは言え、PL*SQLをkshで包むって方法もあるわけだし。
ジェズイットを見習え |
Rubyにはテスティングフレームワークがあるし、kshよりはテストが書きやすそう、というのはどうでしょう(しかしbashにはbashunitがあるという罠)。
bashは、USL正統ではないから立ち位置はRubyと同じなので問題ないですが(というかこちらの環境ではDBCSをうまく扱えないのでスクリプト言語としては問題外だったり)微妙かな?<br>なんで利用したいかと言えば結局、開発が楽だという1点なのでそれで押し切れるかどうかかも。<br>ちなみにAtsukoさんのを読み返していて気付いたけど、公式コンパイル言語=Javaというのがあるから、同じOOな設計手法が採用できるという論点が(最初からそういう論点は無視していたけど、意外と)いいかも知れないかも。
ちょいと良心は咎めるが、OOがどうしたとか言うなら再利用性云々も出してみるか。
JavaがおっけーならいっそJRubyとかGroovyとか、というのは冗談にしても、「Javaで開発すればよい」みたいな話になったりしそうで怖いですね。<br>ooがどうしたという以前に、開発・保守の手間の側面だけで話ができれば理想的(というか当たり前)ですが、「数値化できない」で切り返される相手じゃどうにもならないか……。