日々の破片

_ MicrosoftのAPIの謎を推理する

ODataの$filterを書いていて謎現象に苦しむ。

最初、Fooテーブルのbarカラムが32のやつを読もうと次のように書いた。

/FooBar.svc/Foo(bar='32')

するとエラーになって、どうも複合主キーの場合は()に主キーはすべて書かなければならないようだと気付く。で、次のように書く。

/FooBar.svc/Foo?bar='32'

書いたつもりで何か間違えていたのか、とにかくエラーになって、しょうがないので、ODataのドキュメントをちゃんと読んでみた。

で、Filter System Query Option ($filter)のOperatorを見ながら、$filterというのを使えば良いのだな、と次のように書く。

/FooBar.svc/Foo?$filter=bar Eq '32'

が、エラーとなる。

何度も表を見て、オペレータがEqなのを確認して、もう一度、二度、三度やってあきらめた。

嘘ばかり書きやがって。で、2番目の方法に戻してうまくいったのかなぁ。

後になって、やはり$filterを使わなければならなくなって、再度見返して、Exampleのところを見て驚く。オペレータはEqなのに、Exampleにはeqって書いてあるじゃん。で、

/FooBar.svc/Foo?$filter=bar eq '32'

だとちゃんと答えが返ってくるではないか。

この表を書いたやつは、Operatorっていう言葉をTitleと誤解してるんじゃないか！ ぷんぷん。

で、それはそれとしてWordで書き物していて、例によってgetFooBarと打ち込むと、WordがGetFooBarにわざわざ直して赤い波をつけてくれるから、インテリタグとかいう不細工なやつを使って元に戻していて、なぜ、ODataの表でOperatorに嘘が書いてあるのかに思い当たる。

おそらく、あの表を書いたやつは、Operatorには正しくeqと打ち込んだに違いない。しかし、Wordが気を回してEqに変えて、それに気づかずにHTML化したのだろう。きっとそうだ。

そこで、なぜ.NET Frameworkのメソッドやプロパティが不細工に大文字で始まるのかについての不思議が氷解したような気がした。

PASCAL出身のデザイナーが悪いのではなく、おそらく、APIを決めた連中はちゃんと、disposeとか、notifyとかgetDisplayInfoとか定義したに違いない。しかし、彼らのツールは仕事柄じゃなくて勤務先の都合でWordだから、DisposeとかNotifyとかGetDisplayInfoとかになってしまって、しかしそれに気付く余裕もなくどんどこ記述しては実装者に仕様を渡していくから、実装者はドキュメント通りにDisposeとかNotifyとかGetDisplayInfoとかにしてしまって、気づくともう後戻りはできない状況になっていたのだろう。

得心した。

【旧商品】Microsoft Office Word 2010 アカデミック [パッケージ](-)

アカデミーパックは安いな。（APIが汚くなるというデメリットはあるが、ワープロとしてのできは良いとは思う）