0
マークアップ拡張は、XAMLの手続き型プログラミングの組み込み方法といえますか？この声明の限界は何だと思いますか？Markup Extensions、XAMLの手続き型プログラミングを組み込む方法？
たとえば、純粋なXMLと比較すると、マークアップ拡張は「操作要素」のようになりますが、オブジェクトツリーの一部ではありません。
A
答えて
0
は、いくつかのマークアップ拡張機能は、（そう、その使用量は地獄のように宣言型である）タグのより広範な利用をすることによって何ができるか記述するちょうどより多くのインプレース方法です：
<TextBox Text="{Binding Path=Foo}">
<TextBox>
<TextBox.Text>
<Binding Path="Foo">
</TextBox.Text>
</TextBox>
一般的な拡張機能については、hereを参照してください。 {} -Syntaxは、対応する拡張型のインスタンスを使用してその間のコードを処理するようにコンパイラに指示します。これは、もちろん、オブジェクト指向のコードであり、これまで決して決して手続き的ではありません。それを信じてもらえません。たとえM $の人々でさえ、コーディング方法が分かっていても大丈夫です！
0
いいえ、純粋に宣言的です。決して手続き的ではありません。
舞台裏では、マークアップ拡張の手続き型コードではありませんか、何か面倒ですか？ – mihajlv
コンパイラ（およびその拡張機能）を命令的に実装する方法は、XAMLマークアップ自体を命令型プログラミング言語にするものではありません。どのようにウィンドウがどのように表示されているのか、どのプロパティがリソース辞書にあるのか、ウィンドウが描画されるのか、プロパティがどのように設定されるのか、アイテムがリソース辞書にどのように置かれるのかを記述しません。マークアップ拡張は単なる拡張であり、実装する方法ではなく、使用していると宣言しています。 –
あなたが言っていることを見て、私が考えていたのは純粋なXMLと比べれば、マークアップ拡張は「アクション要素」のようなもので、オブジェクトツリーの一部ではありません。 – mihajlv