著作一覧 |
コネクションのキープアライブが、矛盾してるんだよな、ははは。
って言うか、RSTやFINを受けたことを、上位に判定させないクラス構造が腐れてるだろう。(java.netもそうだったような。非同期メソッド使えば判定可能なのかな?)
やっぱりな。
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://tempuri.org/")] public enum GraphicsUnit { ///これ自身は、enumだから、整数として利用可能。したがって、プログラム内で、World, ....
GraphicsUnit g = World + Pixel; // 実際にはGraphicsUnitでは複合化はしないと記述しても問題ない。これが、複合化enumだ。 しかし、SOAPパケットを見ると
<Unit>Point</Unit>と、文字列として記述される。これは、XSD仕様から正しい。 ようするに、C#のenumの仕様が腐っているのが原因だ。 もちろん、気持ちはわかる。 強い型付けをしたい場合に複合が必要な場合はある。
void SetFontSylte(FontStyle s); foo.SetFontStyle(FontStyle.Bold + FontStyle.Italic);しかし、これはXSDのenumeration(xsd:restriction base="xsd:string")で表現できない。
<!-- こうは書けない --> <style>Bold+Italic</style>したがって、複合化されることがあるenumをXmlSerializationする場合のベストプラクティスは、以下のような定義だ。
[serializable] class Foo { private EnumHoge hoge; // 分散用publicプロパティではintにする。 public int HogeValue { get { return (int)hoge; } set { hoge = (EnumHoge)value; } } // 非分散のアクセスにはこちらを利用する。 // もし、publicアクセスが必要なら、このクラスはプロクシ生成用の // 値オブジェクトとして、別にホンモノを用意するしかない。 internal EnumHoge Hoge { get { return hoge; } set { hoge = value; } } }これだと、XMLシリアライゼーションは、HogeValue要素で行われるため、整数値として複合化された値が利用されるからだ。
見識。でも、次で導入されるんだっけ?
多くのユースケースでは、FontSylte.Bold + FontStyle.Italicな型強制が有効だから、C#の選択が悪いとは思わない。それが、Webサービスと合わない部分があるということだが。
rufeinさんと、joesaisanさん、どうもありがとうございます。当然のことながら、はてなアンテナを開発された方と、tDiaryのリンク元機能を実装された方(たださんかな)。世界を広げるのに役立たせていただいてます。
_ 上のほうで「複合化」とか書いているが、正式にはビットフィールドとして扱うことが可能な=フラグ属性が付いた列挙ということのようだ。
Soapプロクシジェネレータがこの属性値を見た場合、シリアライズ時に自動的にintへ変換する(かつXSD上はxsd:intとする)というのが理想的な対応になるだろう。
HTTPSでなぜ可能かは、パケット自体を見て見るしかないが、何しろHTTPSだからなぁ。サーバー側にフィルタをかまして、HttpRequestから直接読めばいいんだろうが、いささか面倒なんで謎のまま放置しとこう。予想1:HTTPSならバイナリシリアライゼーションを利用している(どうせ可読性は無視できるんだし−が無茶だろうからありえないだろう)、予想2:想像もつかない単なるバグ。
それより、放置後のタイムアウトが気になる。どうしようかなぁ。
ジェズイットを見習え |