C#では、次のコードはコンパイルされません。
class Foo {
public string Foo;
}
問題は、なぜですか?
より正確には、これはコンパイルされないことを理解しています(引用):
メンバー名はそれらを囲む型と同じにすることはできません
いいよ。私はそれを理解します、私はそれを二度としないでしょう、私は約束します。
しかし、私は本当に理解していませんwhyコンパイラは、囲んでいる型と同じ名前のフィールドを取得することを拒否します。それができない根本的な問題は何ですか?
厳密に言えば、これはC#によって課される制限であり、おそらく構文の利便性のためです。コンストラクターにはメソッド本体がありますが、ILのメンバーエントリは ".ctor"として示され、通常のメソッドとはわずかに異なるメタデータを持ちます(Reflectionクラスでは、ConstructorInfoはMethodInfoではなくMethodBaseから派生します)。私は試していませんが、外部型と同じ名前のメンバー(またはメソッド)を作成できないようにする.NETの制限があります。
私は興味があったので、.NETの制限ではないことを確認しました。 VBで次のクラスを作成します。
Public Class Class1
Public Sub Class1()
End Sub
End Class
C#では、次のように参照します。
var class1 = new Class1();
class1.Class1();
Fooはコンストラクターの名前として予約されているためです。
あなたのコードが許可された場合-コンストラクターを何と呼びますか?
コンストラクターを特別なケースとして扱い、メソッド/メンバーのバインディングに新しいルールを導入することでこれを行うことができたとしても、それは良い考えでしょうか?ある時点で必然的に混乱を招きます。
メンバー名がクラスのコンストラクターの名前と衝突するためですか?
正しい方法と間違った方法があります。
C#で許可されないのはなぜですか?
それはそうする理由がないからです。なぜあなたはあなたの人生でそのような混乱を作りたいのでしょうか。
別の投稿がvb.netの例で証明されており、制限されるべきではないので、CLRはそれを許可すると思いますが、CLRが動作するのと同じルールに基づいてアプリケーションを作成したくありません。 。引数は多重継承と同じレベルで機能すると思います。はい、一部の言語で実行できますが、混乱を引き起こします。したがって、私の答えは、あいまいさと混乱を減らすことであり、c#パーサー/コンパイラに基づいています。 C#チームによる設計の選択。