プログラミング：.NET

Web への移植を考えると…

シャノン — Fri, 05 Sep 2008 19:07:00 GMT

.NET Framework 3.0 にすっかり乗り遅れてるんですが、ちょいと質問。
「今は exe ファイルの形態をとっているが、将来的には Web アプリに移植したい」っていう要望があるとき、WPF はちょーおすすめの選択肢になり得るでしょうか？
XBAP 化や Silverlight 化するにあたって、例えば Windows Form アプリを ASP.NET や JSP に移植するよりも、すっげー楽、っぽい？
もしそうなら、今期の開発で VS2008 を使わせてもらえる可能性が出てくるので…もう 2003 で DataGrid と格闘するのは勘弁してほしいのですよぅ。

ちなみに、Webアプリってのはイントラ環境…のはず。完全信頼はもともと必要としてないけど、XBAP とか Silverlight って Oracle にアクセスはできる？
あ、「Mac からも見れるように汁！」って言われそうだなぁ…Silverlight なら Mac でも大丈夫だっけ？

Linq の Where って

シャノン — Fri, 05 Sep 2008 13:31:00 GMT

なんで条件に Predicate<T> じゃなくて Func<T, bool> を使うの？
昔のことは忘れたい主義なの？

AuthenticationManager.RegisteredModules

シャノン — Mon, 04 Aug 2008 16:50:00 GMT

IEnumerator 型を返すプロパティってはじめて見たなぁ。戻り値に返すメソッドも見たこと無いけどさ。

コマンドラインパーサ

シャノン — Mon, 28 Jul 2008 14:32:00 GMT

ちょっと実用的なコマンドラインパーサを作ろう、と思っているわけです。C# で。
困ったことに、コマンドラインパーサってのはどんなアプリでも利用可能ですから、こういうものを作ろうと思い立ってしまうと、これが出来上がるまで他のどんなアプリも作りたくなくなります。俺の悪い癖です。

で、悩んでいるのが、

既存のアプリのコマンドラインの仕様を変えずに移植できるように柔軟性を持たせるか
このパーサライブラリを使う以上は使用可能なコマンドラインの仕様にある程度の制限があるのも止むなしとするか

ということ、とか。
まぁほら、後者の方が作るのは簡単なんですけど、前者ができるならそれに越したことは無いじゃない？　みたいな。

あとは、パラメータを指定するにしても、世の中にはいろんな方式のアプリがあるわけですよ。
例えば、オプション「/foo」にパラメータ「bar」を指定するのでも、

/foo bar
/foo:bar
/foobar

なんてのがあります。
2と3は技術的にはあまり違いはありません。見た目的には2の方が好きです。
が、1と2には大きな違いがあります。
コマンドラインは Main に文字列配列として渡されますが、1 は /foo と bar が別の要素になるのに対し、2 は単一の要素になります。
当然、1の方が解析は面倒です。「bar」を処理するときに、その前の要素が「/foo」であるか、そうでないかでは意味が違ってくるからです。
このため、コマンドラインパーサは、簡易な状態遷移機械ということになります。
ちなみに、3つの中では見た目的に1が一番好きです。

このように、コマンドの順序を意識しなければならないこともあれば、順序はどうでもいい場合もあります。
例えば、オプション /hoge と /hage があるとき、以下の2つは

/hoge /hage
/hage /hoge

どっちでもいいじゃないですか。

もっと複雑な例になると、/foo:X=1,Y=2,Z=3 なんていう例も考えられます。もちろん、/foo:Z=3,X=1,Y=2でも同じ意味でなければなりません。
正直、こんなのをパースするのは面倒です。
で、正規表現を使っちゃえばいいじゃないか、と思い立ったわけです。キャプチャしてくれますから。

ただですね、上のは敢えてスペースを詰めて1つの文字列になるように書きましたが、/foo x 1 y 2 z 3 でも同じ意味でいいじゃないかと。
で、そういう場合に、

/foo
/foo x
/foo x 1 y
/foo x 1 /bar

1～3なんかは不正なコマンドラインなわけですが、正規表現でこれらを不正だと見破るのは面倒くさいです。
4 は正当なコマンドラインですが、「/foo x 1」と「/bar」は別のオプションです。が、正規表現だと、「/foo」と「x」と「1 bar」に分けちゃったりするのです。
一番簡単な方法は、/foo:x=1 /foo:y=2 /foo:z=3 という風に書かせて、可変個引数を認めないことですが、それもかっこ悪いなぁ、と。

面倒くさいです。

最近、C# の行末のセミコロンがうっとうし<del>く感じる件について</del><ins>い</ins>。

シャノン — Thu, 24 Jul 2008 15:44:00 GMT

邪魔。

これでもダメか…っ！

シャノン — Wed, 23 Jul 2008 15:39:00 GMT

IVSMDCodeDomProvider を使っても、C# のコードをメソッドの中まではパースしてくんない。うげー。
やはり Colorizer 方面から攻めるしかないか。面倒くせー。

インターフェイスの要件は最小であるべきか？

シャノン — Thu, 17 Jul 2008 16:05:00 GMT

なんだかぱっとしないタイトル。
ここで言う「インターフェイス」とは、多重継承できるあの interface じゃなくて、もっと一般的な意味でのそれです。約束事、みたいな。

例えば、メソッドの引数に何かコレクションを受け取るとして、その型はどう宣言すべきか、と。
IEnumerable<T> か、ICollection<T> か、IList<T> か、はたまた T[] か。

極めて単純無思考には T[] 。
しかし、T[] のほとんどの特性は IList<T> も備えているため、俺は個人的に IList<T> を好む傾向にある。
多次元配列なんかは、もはや配列をそのまんま使うんじゃなくて、何らかのクラスを作ったほうがいいと思う。

しかし、ランダムアクセスの必要が無ければ、IEnumerable<T> でも十分ではある。
そういう時、IEnumerable<T> とすべきか否か。

ちょっと引っかかるのは、ICollection<T> や IList<T> は無限リストを許容しないが、IEnumerable<T> は許容するというところ。
ということは、IEnumerable<T> を引数に取るメソッドは、すべからく無限リストに対応すべし、ということになるか？
遅延処理を意図したロジックならいいが、そうでない場合もあるだろう。
IEnumerable<T>.Count() なんかは ICollection<T>.Count でもよかったんじゃないだろうか。無限リストに使ったらオーバーフローしたぞ。
まぁ、ICollection<T> や IList<T> を受け取ったとして、要素数が Int32.MaxValue 個ある場合にちゃんと処理できなければならない、というのもなかなか酷ではあるのだが。

また、これは感覚的な問題でもあるが、用途としては IEnumerable<T> で十分であっても、IList<T> を使いたいという心情もあると思う。
ちょっと前の var 論争でもあった意見だが、「IEnumerable<T> ではコレクションのような気がしない。IList<T> ならコレクションであるという意図が込められる」みたいな。

また別問題ではあるが、独自のデータ構造を作るか否かという問題もある。
例えば、Pair<T, U> という既存の型があった場合、あらゆる2値の組み合わせは Pair<T, U> で事足りるか、ということ。
Pair<T, U> は、それぞれの値の意味を理解しないので、.First とか .Second とかいうメンバ名にならざるを得ない。
人の名前を表すのに、FirstName と LastName というメンバを持つクラスを作るか、Pair<string, string> で済ませるか、とか。
独自のデータ型を作らずに既存の型を最大限活用した場合、

メンバの意味がわかりにくくなる
ジェネリックの入れ子が深くなる

という問題が発生するわけだが、どうよ？　という。

LinkedList<T> が IList<T> を実装しない件について

シャノン — Thu, 17 Jul 2008 14:49:00 GMT

確かに、特性を考えれば妥当だけど（IList<T> は添え字によるランダムアクセスが可能、LinkedList<T> は不可能）、名前がなぁ…

IList<T> は IArray<T> とかいう名前の方が良かったんじゃないのか。

LINQのヴァカ…

シャノン — Wed, 16 Jul 2008 16:06:00 GMT

なんで DefaultIfEmpty はデフォルト値を自分で指定できるのに、FirstOrDefault は指定できないのさ…
作るからいいもん。ふんだ。

Outlook 2007のアドインなぞ作ってみる

シャノン — Fri, 04 Jul 2008 02:37:00 GMT

あくせんくとうちゅう…