10/05/28 22:00:16 QLlJeu5r
>>74
GL が汎用のビットマップ操作のクラスを実装したものだと想像するが、
その作りだと、あまりにも簡単にふっとびすぎるだろう。TJSのメリットである安全性を犠牲にしてまでつくる構造じゃない^^;
layer の mainImageBuffer や mainImageBufferPitch はプラグイン内部でだけ触るべきものだね。
OctetBuilder の begin や end も同様で、任意の場所からアクセスさせたいなら、例えば、インターフェースは
GL.flipScanLineBytes(buf, begin, end) として、begin と end が null ないし voidなら、それぞれ buf の
先頭と末尾を意味させて、数値ならオフセット値として扱う、といった構造にするのが妥当。
さらに buf の範囲外なら例外をなげれば万全
引数の型判定できるんだから、処理対象として、Layer を渡された時と、OctetBuilder を渡された時を
区別して内部分岐してどちらでも同じような感覚で使えるようにするのがユーザ的には一番使いやすいだろうね。
ただ、そうすると、Layer と OctetBuilder のインターフェースが違うのが気持ち悪いというのがあるかもしれない。
それを嫌う場合、逆転の発想で、最初から両方に同じインターフェースをはやしてしまうという手がある。
まず、もろもろ必要なポインタ操作をうけつけるインターフェースをネイティブで準備して、ObjectBuilder はその
インターフェースを単純に継承した実装にする。Layer 用には、同インターフェースの操作を、Layer の実インスタンスに proxy して
アクセスするような実装を準備して、メソッド呼び出しの時点でフックして追加で NativeInstance をを持たせるか、あるいは
単にそれで作ったクラスと Layer を多重継承させれば良いだろう
それらのオブジェクトを処理する機能側では、まず対象オブジェクトがそのインターフェースをもっているかを
NatigeInstanceSupport 経由で確認して、もってなければエラー、もってれば、そのインターフェースを直接
ネイティブでさわるようにすれば、データの扱い的にも安全、コード的にもすっきり、さらに性能も出せる