日々の破片

_ Rjb-1.0.9

Rjb-1.0.9。

戻り値の型がjava.lang.Objectかつ実際の型がjava.lang.StringかつRjb::primitive_conversionが真の場合に、RubyのString型のオブジェクトに変換するようにしました。

その他、Javaのメソッド呼び出し時に、型がRubyのBignumでかつint64の範囲の場合、ゴミをJavaに与えていたのをjava.lang.Longに変換することと、変換できない場合は例外をスローする修正の追加（テスト中に気付いた）。

x64 Linuxで、Doubleのコンストラクタ呼び出しに限りなく0に近い値が与えられていた良くわからない現象の対応。（x64のdoubleも64ビット幅だと思うのだが128ビット幅なんだろうか？）

_ 個性無用のジャングル

無責任な放言ではあるが、コードに求められるものが、

* オブジェクト指向はテストしづらいから使うな

* ひとつの長い流れにしたほうが見通しがいい

* エンジニアに個性なんて必要ない

* 本格的なコードは書くな、ステップ数を短くしろ

で、かつ、給料とか諸条件が良かったりして、まだやめないで済ませたい場合にはどういう方法で折り合いを付けることができるだろうか、考えてみる。

すると、ここで求められているコードは、まさに単純な自動生成向きなこことに気付く。

だらだらコードを機械的に吐き出していけば良いように見えるからだ（最後の条件が2番目の条件と矛盾しているようにも思うけど）。

ジェネレーションギャップ用のスタブも不要だし（というか、オブジェクト指向言語の特性を生かさなければ、ジェネレーションギャップパターンは適用するのが難しいから、逆に向いていることになる）、常に最初から生成して行けば良い。真に重要な定義ファイルを確保しておけば、いつでも再生産できるので、それで良いのだ。

実際のところ、納品物と開発するものが同一である必要はないのだから（等しい必要はもちろんあるのだが）、そんなことを試してみるとおもしろいかもなぁ、とか思った。

_ 用語のアフォーダンス

確か、以前角谷さんが用語が持つアフォーダンスというような記事を書かれていたのを読んだ覚えがあるのだけど、アフォーダンスとsite:kakutani.comでは見つからない。

確か内容は（まったくの記憶違いかも）、assertを表明すると訳すか、検証すると訳すかについてだと思うのですが（書いていて自信がないけど、もしかしたらBDDに関することかな？ だとすると以下は見当外れで、僕が自分で勝手に考えただけか、あるいは自分で咀嚼しきった何かなのかも）。もし、出典をご存知のかたは、ツッコミで教えていただけないでしょうか？

英辞郎でassertionをひくと、名-1として主張、表明といった定義があって、名-2にはコンピュータ用語としてプログラムの形式検証における成立条件 という書き方をしている。

テストプログラムの、assertEquals(0, foo.getCount()) を実行するということは、fooの動作を検証しているといっても間違いではない。というか、実行しているときは表明しているのではなく、検証している。

では、テストプログラムを書いているときはどうだろうか？

assertEquals(0, foo.getCount());

と記述した時点では、foo#getCountが未実装の場合さえある。したがって、この行を書いている瞬間は、まさにfoo.getCount()が（その直前のプログラムの記述にしたがって動作している限りにおいて）0を返すというあるべき振る舞いを表明しているとしか表現しようがない。

テストプログラムは、すると2つの状態を持つ。記述時点での表明と、実行時点での検証だ。

したがって、assertionを表明と訳すか、検証と訳すかは、どちらを主とみなすか、の差だ。プログラマはまずプログラムを実行する人よりも前にプログラムを書く人である。したがって、assertionは検証ではなく、表明であるべきだ。

というような感じ。

#わかりやすさ（表明っていう日本語は普通の日本人の語彙には入ってないとおれは信じる）と、説明ゼロ（同じ理由から）で意味を通せるので、「検証」と訳して突っ走りながら、ふと振り返って考えて、やはり「表明」であるべきだろうか、とちょっと迷っているので、ご意見もツッコミ歓迎です。