XML再考

XMLについて思うことがあったので
ぜんぜんまとまってないけど書き綴ってみる。
用語の使い方とかむちゃくちゃだし
ぜんぜん厳密にしてないので注意

・アプリケーションドメインのデータ構造 Appがあるとする。
これは仕様変更によって頻繁に変わる可能性がある。
そして App はなぜか XML で表現しないといけないという条件があるとする。

・XMLは階層型データ構造を表現するDSL
階層型データ構造にマッチしないものはXMLにマッピングが難しい。（※1）

・変更の依存関係グラフを構築できる。

変更の依存関係グラフ
例えば AppXML を App を無理やりXMLにマッピングしたものとする。
( Text ) ← ( XML )　← ( AppXML ) ← ( App Module ）
　　　　　　　　　　　 ↓
　　　　　　　　　 （ App ）※これが最も変更されやすい
構造に変更があった場合はエッジの矢印とは逆方向に変更が伝搬する。
TextとXMLはそうめったに変更されるものではないとして
AppXMLはAppの変更を伝搬してしまうため、Moduleが安定しない。（※2）

アイディア　その1
※1と※2の理由があるためXMLで直接Appを表現するのは
よくなさそう。
ということでもうちょっと考える。

まず表現したいデータ構造の一部が階層型であった場合は
XMLで表現すると自然。

そうでない部分、例えばDictionaryなどのデータ構造などは
Key Value Pairを採用すれば
XML上にプロパティシステムを構築することができる。
それをPSというDSLとしよう。
PSはXMLによって定義される。

そのグラフはこうなる。

　　　　　　　　　　 ( PS Module ）← ( App Module )
　　　　　　　　　　　　　↓ ↓
( Text ) ← ( XML )　← ( PS )　← ( PSを使って定義したAppXML )
↓
　　　　　　　　　　　　　　　 （ App ）※これが最も変更されやすい
PSはこういうやつね

otf
21


こうすることで Software の App からの App Module の変更の影響度を少なくすることができる。

一言でいうと適切な粒度でDSLを作れば
いいんでね？って話

結論
XMLでAppレベルのDSLを構築するのはおかしい。
XMLで構築したDSLで記述したAppXMLはOK
XMLを頼りすぎるのはやめなイカ？
※XMLだからRuntimeに変更できるとか、
XMLだから変更に柔軟であるといった誤解を持ってる人が多いと個人的に感じる。←偏見

参考
依存関係グラフとかは　「アジャイルソフトウェア開発の奥義」

コンストラクタの例外について


twitterでコンストラクタの例外について触れたが、
興味深い問題だったので再考。
自分の考えを書き出してみる。

* まずコンストラクタ例外の必要性について

おさらいも含めて例外の必要性を考えてみる。　

データ抽象型は、
・ 型
・ 不変条件
・ 事前条件
・ 関数（生成関数　←　これを定義したのがコンストラクタ　、問い合わせ関数、命令関数）
　で定義される。（厳密な説明ではないけど）

データ抽象型は値（オブジェクト）の集合であるから
すべての値は不変条件を満たす。

　
数理的にはこうだけど、
契約による設計　Design By Contract（以後 DbC ）という技法を用いて
ソースコード中に不変条件と事前条件の一部を記述することができる。
特に事前条件はそれぞれの関数に記述する。

データ抽象型の定義により、
生成関数にも事前条件がある。
事前条件が満たされなければそもそも値は生成されない。

もし契約違反があれば例外やエラーなどを発生させる。
契約違反といっても

1. プログラマが間違った記述した。
2. "計算機が正しい演算を行っていること"、データベースが正しく接続できること"などの暗黙の条件が満たされなかったこと。
　
の2種類がある。
　
1は、
妥当でない入力（"aaa"を数値にパースしようとした等）をした場合などで、こういうのはエラーでプログラム停止である。
バグだからね。事前条件を満たすのは呼び出し側の責任だからね。
中にはコンパイルタイムエラーにできるものもある。

2は、
現実的には、DbCでも記述するのは不可能で
もしそういった契約違反が発生した場合でもプログラムを続行しなければならない。
例外を使うことでこれが実現できる。

ということで、
・生成関数には事前条件がある。
・2のような契約違反を実現するために例外が必要。
　
だからDbCを使うならばコンストラクタの例外は必要な状況があると思うんだ。
　

・言語の問題 C++ C# Haskell

　あとで書く(^q^)

ChaberiSwitcher

今まで公開しまいと思ってたけど
これからは自分の作ったものを全面的に見せていきたい。


技術を隠すのは自信がないみたいでいやだし
もっと俺の創ってるもの、やりたいことを知ってほしい！


ということでまず第一弾。
「Chaberi Swticher」


チャベリっていうチャットサイトをご存知の方は多いんじゃないかな？
多分日本で一番有名なチャットサイトだと思うんだ。
http://www.chaberi.com/


このチャットサイトは、登録しないですぐチャットできるのが
魅力の一つなんだけど、逆にユーザーの切り替えなどが
少しめんどくさいんだ。


俺のChaberi Switcherを使えば簡単にユーザーの切り替えができる。
みんなもよかったら使ってほしい。


ここだけの話、このソフトを使ったらBANされてもすぐ回避できる。
あくまで使うときは自己責任でお願いしたい。
悪用しないでね♥


ダウンロードは下記のURLから！
http://124.97.22.31/Software/ChaberiSwitcher.zip

ソースコードはこちらから！
http://124.97.22.31/Software/ChaberiSwitcherSrc.zip

C#のメソッドのstring引数にnullが設定されたらコンパイルエラーにする方法を考えたなう

.NET C# 
public struct NotNull<T>
    where T : class
{
    public class Null { }
    public static implicit operator NotNull<T>(Null other)
    {
        throw new InvalidOperationException();
    }

    public static implicit operator NotNull<T>(T other)
    {
        return new NotNull<T>() { value = other };
    }

    public static implicit operator T(NotNull<T> other)
    {
        return other.value;
    }

    T value;
}

static void f(NotNull<string> notNullText)
{
    // もとにキャストするのがちょっとめんどいけどね
    string text = notNullText;
}

static void Main(string[] args)
{
    f("not null");

    // Compile-Time error
    // f(null);

    // こういう型情報を与えてしまうようなやつは、この方法じゃ無理
    // f((string)null);

    Console.Read();
}

だけどいくつかの弱点がすでにわかってる。
1. エラーメッセージに意図が含まれていない。
2. 型情報を持つ null には効果がない。
3. もとの型にキャストするのがめんどくさい。

あと別の方法としてはC# DbCでできねーかなって考えて
試しに使ってみたけどよくわからんかったわ。
どうやらCodeContractsっていうアドインをいれないといけないらしい。

MSDNの説明に不満

プログラミング ASP.NET

http://msdn.microsoft.com/ja-jp/library/ms178366(VS.80).aspx

データ バインディング式は、コントロールの DataBind メソッドまたは Page クラスが呼び出されたときに解決されます。

Pageクラスが呼び出されるってどういう意味だよ！！

http://msdn.microsoft.com/ja-jp/library/acxb7xys(VS.80).aspx

Eval メソッドは DataBinder.Eval メソッドを呼び出し、GetDataItem メソッドを使用して、式が評価される対象となるオブジェクト参照を解決します。

わざわざ日本語に訳さないで

DataBinder.Eval(GetDataItem(), expression)

と等価

みたいに書いてくれ！
っていうかEval関数はPageだけじゃなくてGetDataItemがないUserControlでも使えるのにその場合どうなるかの記述がないぞ！

調べたいことが一向にわからんぞ！！