Pourquoi les noms de membres C # ne peuvent pas être identiques au nom de type qui les entoure?

Question

Le code suivant ne compile pas:

class Foo {

    public string Foo;

}

La question est: pourquoi?

Plus exactement, je comprends que ce ne compile pas, parce que (je cite):

les noms des membres ne peut pas être le même que leur joignant type

Ok, très bien. Je comprends que je ne vais pas le faire à nouveau, je le promets.

Mais je ne comprends vraiment pas pourquoi le compilateur refuse de prendre n'importe quel champ ayant le même nom qu'un enfermant type. Quel est le problème qui m'empêche de le faire?

Answer 1

Strictement parlant, c'est une limitation imposée par C#, probablement pour des raisons de commodité de la syntaxe. Un constructeur a un corps de méthode, mais son membre à l'entrée dans IL est noté que ".ctor" et il a légèrement différente de métadonnées que la méthode habituelle (Dans le Reflet des classes, ConstructorInfo dérive de MethodBase, pas MethodInfo.) Je ne crois pas qu'il y a un .NET limitation qui empêche la création d'un membre (ou même une méthode d') avec le même nom que la surface externe de type, bien que je n'ai pas essayé.

---

J'étais curieux, donc je confirme qu'il n'est pas un .NET limitation. Créer la classe suivante en VB:

Public Class Class1
    Public Sub Class1()

    End Sub
End Class

En C#, vous pouvez référencer comme:

var class1 = new Class1();
class1.Class1();

Answer 2

Parce que Foo est réservé comme nom du constructeur.

Donc, si votre code était autorisé - comment appelleriez-vous le constructeur?

Même s'il était possible de le faire en considérant le constructeur comme un cas particulier et en introduisant de nouvelles règles dans la liaison méthode / membre - serait-ce une bonne idée? Cela créerait inévitablement de la confusion à un moment donné.

Answer 3

Parce que le nom du membre est en conflit avec le nom du constructeur de la classe?

Answer 4

Il ya une bonne façon de le faire et une mauvaise façon de le faire.

Pourquoi Ne pas C# permet-il?

Parce qu'il n'a pas de raison de le faire. Pourquoi voulez-vous créer une telle confusion dans votre vie.

Je pense que le CLR permet, comme un autre post prouve avec un vb.net exemple et il ne devrait pas être restreint, mais je ne voudrais pas créer une application basée sur les mêmes règles que le CLR opère. L'abstraction rend le code plus clair. Je pense que l'argument fonctionne sur le même niveau que l'héritage multiple. Oui, il peut être fait dans certaines langues, mais il provoque de la confusion. Ma réponse serait donc de réduire l'ambiguïté et de la confusion et est basé dans le c# analyseur/compilateur. Un choix de conception par l'équipe C#.