free as in air

2007|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|09|11|12|
2012|03|04|05|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|03|04|06|09|
トップ «前の日(03-04) 最新 次の日(03-06)» /追記

2008-03-05 この日を編集

§ [rjb] todo

 unloadでもっと環境を綺麗にする。unbindのテストを考える。more short, beauty, right and clear code.

 ところでコミットしたんだけど、rjbexception.cからはrjb_s_load()(rjb.c)を参照できないので、rjb_s_throw()ではrb_funcall()で解決してたりして凄く悩ましい。安易にextern増やすのも嫌だし。

 load.cに移してそっちでexternするのがいいのかも。

 追記:書いたのは(2行目から下は消化済だけど)、あくまで俺のtodo。Rjbプロジェクトとして…、という話ではない。早々にやらなきゃなと思っているだけで、いつまでにやる、とかいう話でもない。普通に使う範囲にはたぶん影響しない。

 unloadが気になっているのは、testのteardownでunloadしてるけど、ちゃんとキレイになってないので後発のテストでちゃんと失敗しないところがある、と考えてるから。あ、いや、違うな。load/unload自体のテストがないってことか。現状ではRjbのクラスメソッドを読んだ途端にグローバルに状態が変わる。状態が変わっていく中で操作してエラーにならんかとか見ないといけない。少なくともsegvは避けたい。グローバルに状態を変えないようなデザインにもできると思うのだが、しかしそれでは使いづらいと思う。(常にRjbインスタンス経由でアクセスする(でなきゃ継承するとかブロック使うか)ことになるのかな。それだとカジュアルには使いづらいだろう。)

 より良いコードにするのはユーザには、まあ、関係ないか。なくはないけどないといえばない。今のコードも結構イケてる。少なくとも、全然ダメとは思ってない。(俺のコードは微々たるものなので、こう書くとなんか偉そうだが)

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

<< arton [うーん、rjb_s_loadはRubyに移出している関数で、移出元はすべからくメインのrjb.cに入れたい。したがっ..]

<< arton [niが確定モードになってたものだから、Enterで送信されてしまいました。 load.cへ移動してそこでextern..]

<< kuwa1 [それに近いことになりました。]


2009-03-05 この日を編集

§ [devel] 休み

 農業などす。