FieldAccessExceptionでハマる

　相場はとうとう5/16につけた高値を堂々超えてきた！今日陰線を引くのは気になるが、当面上昇基調くさい。でもその前にちょっとだけ下落してくれると嬉しいな。コールの売りポジを縮めたい。

　さて前回書いた件で、動的にクラスを作るテクニックに取り組んでみたはよいものの、いざ実行してみたらFieldAccessExceptionが出てうまくいかない。
　本当にこの手のセキュリティがらみの問題にぶつかると資料が乏しくて難儀する。分野的にマイナーなのでWebで調べてもヒット数が少ないし...。過去にもJavaのセキュリティで何時間も悪戦苦闘して結局お手上げだったことがあった。

　まあセキュリティ関係のAPIは、何を許して何を許さないかを柔軟に決められなくてはいけないし、典型的な使い方であれば簡便にできること、パフォーマンスに影響を出さないこと、などを考えるとAPIが複雑になるのは仕方ないとは思う。
　一般的にどんなAPIでも、設計者は全体を統一的に無駄なく記述できることを目指すのに対し、その結果抽象度が高くなりすぎて学習が困難になる、というのはよく見られることだ。「俺のしたいことはこんな単純なのに、なぜこんな面倒な手順を踏まなければならんのだ」とライブラリに対して思ったことは多くある。
　数年前でもJ2EEには複雑でクラスのリストを見ただけでげんなりするのがいっぱいあったが、きっと最近はさらにそうなのだろうな。抽象度と学習のしやすさのトレードオフは将来もずっとソフトウェアにとって重要なテーマだと思う。

　一応、今回の件については、動的アセンブリから自分のアセンブリのメソッドを呼ぶように回流させることで問題は回避できることはわかっているけれども、当初の予定の手法で実装できれば格好いいので方法をMS本家のフォーラムで問い合わせてみた。うまい回答が得られればそっちでいこう。

　しかしMSILレベルでコードを書くのは短いものであってもドキドキする。このレイヤだと型チェックがないので、int型の変数にstringを入れるのも自在である。それでもVisualStudioのデバッガはそういう事態も想定しているらしい動きをするのでなかなか流石。

　一方MSDNのドキュメントはVS2008になってクソになった。フィルタを".NET"にすると.NETの重要な機能のかなりの割合がフィルタから外されてしまうし、かといって全項目にすると項目が多すぎるし、検索をすればローカルのHDDだけを対象にしてすらGoogleで検索するより時間がかかる。ドキュメントはVS2005のを使おうかな...