WPFで、Width / HeightではなくAlignmentプロパティを介してオブジェクトをStretchに設定するのはなぜですか？

Question

WPFのXAMLでは、次のように要素にそのコンテナーを満たすように指示できます。

<Button HorizontalAlignment="Stretch" VerticalAlignment="Stretch" />

要素をStretchに設定するときに、HorizontalAlignmentプロパティとVerticalAlignmentプロパティを使用してそれを行うのはなぜですか？ WPF設計チームがWidth="Stretch"とHeight="Stretch"を使用するのではなく、このアプローチを取ることにしたのはなぜですか？私はそれが計算された決定だったと思います、そして私はその推論に興味があります。

CSSは、他のテクノロジーの中でも特に、幅と高さのプロパティを介してストレッチが行われ、配置が配置に影響を与えるという規則に従います排他的に。これは直感的に思えます。要素をストレッチすることは、その幅と高さを操作することになるからです。要素を引き伸ばすために対応する配置プロパティを使用することは、直感に反し、比較して珍しいようです。これは、彼らが理由なくこのオプションを選択しただけではなかったと私に思わせます：彼らは計算された決定を行い、その背後に理由がありました。

幅と高さはdoubleデータ型を使用します。これは通常、文字列を割り当てることは愚かであることを意味します。ただし、WPFのWindowオブジェクトはWidth="Auto"を取ることができ、double.NaNとして扱われます。 Width="Stretch"をdouble.PositiveInfinityまたはその他の値として保存できませんでしたか？

p.s.w.g · Accepted Answer

double.NaNとdouble.PositiveInfinityはすでに非常に特定の意味を持っているためです。そのような特別な値を、まったく異なるコンテキストで再利用することはかなり悪い習慣です。要素がNaNまたはPositiveInfinity（または、さらに言えば-1）の単位にできないからといって、その値を任意に再利用して別のことを意味する必要はありません。要素のwithを動的に計算したとしても、NaNまたはPositiveInfinityはゼロによる除算を表し、その要素がストレッチするのではなく、計算に問題があることを意味します。

WPFでは、内部でNaNとして格納されるWidth="Auto"を指定できることは事実ですが、これは確かに悪い設計（または、少なくとも非常に良い設計ではありません。少なくとも"Auto"は、実際には数値ではありません）だと主張します。上記の理由により。 WPFチームがなぜ1つの特別な値を許可し、他の特別な値を許可しないことを選択したのかは言えません。ただし、レイアウトアルゴリズムをシンプルかつ柔軟に保つには、それが単に最良のオプションだった可能性があります。 NaNには、その上で実行される算術演算がNaNのままであるという利点がありますが、PositiveInfinityに対する演算の多くはNaNになります。これにより、NaNがPostitiveInfinityよりも特別な値を格納するのに適している場合があります。

GridLength 構造ではるかに優れたソリューションを見つけることができます。これは、目立たない測定値と特別な値（*やautoなど）を適切に表します。 WPFの設計者couldは、同様の構造を使用してすべてのフレームワーク要素の幅/高さを表現していますが、そのため、最も基本的なレイアウトアルゴリズムのほとんどでさえはるかに困難になっているでしょう。