Hier ist ein Beispiel von dem, worüber ich spreche ...
%Vor% Me.MyValue gibt eine Warnung in VB.NET und (der entsprechende Code gibt) einen Fehler in C #. Gibt es einen besonderen Grund dafür? Ich finde es intuitiver / natürlicher, auf die gemeinsame Funktion mit 'Me.MyValue' zuzugreifen - aber ich vermeide es, meine Warnungen auf 0 zu halten.
Hat jemand anderes gerade entschieden, "Nah, es macht mehr Sinn, es anders zu machen" oder gibt es einen technischen Grund, den ich nicht verstehe?
BEARBEITEN:
Danke allen. Ich dachte daran falsch, mehr wie eine "Unterklasse" in OOP. Auch wenn in der Basisklasse etwas deklariert ist, greifen Sie über die vorhandene Instanz darauf zu. Aber diese Beziehung ist nicht identisch mit geteilten oder statischen.
Statische Member werden definitionsgemäß auf der Ebene class deklariert, nicht auf Instanzebene. Daher ist das Zugreifen auf ein statisches Member mit this (oder me in VB) nicht richtig (und stimmt nicht in C #)
Wenn Sie this.something (oder me.something ) angeben, bedeutet dies, dass Sie auf "etwas" zugreifen, das für diese bestimmte Instanz spezifisch ist, während statische Elemente wiederum in allen all Instanzen dieser Klasse geteilt werden.
Es ist irreführend für den Leser Ihres Codes.
Code sollte so geschrieben sein, dass er von einem anderen Programmierer gelesen und verstanden werden kann, der nicht jedes Detail des Projekts kennt. Wenn Sie auf eine statische Variable über eine Instanz zugreifen, sieht diese wie ein Instanzmember aus - Sie müssten die Deklaration überprüfen, um zu sehen, dass Sie sich irren.
Dieser "andere Programmierer" könnte genauso gut nach einem halben Jahr sein.
Me zeigt auf die aktuelle Instanz von Sample1 , während MyValue selbst zur Klasse gehört. Daher erscheint es mir in Ordnung, dass VB.NET Sie warnt.
Übrigens, Java macht es auf die gleiche Weise:
%Vor%Prost Matthias
Sie können nicht auf Felder auf Klassenebene nach this reference zugreifen, und Sie können nicht auf Objektebenenfelder zugreifen, die nach Klassenreferenz sinnvoll sind.
Wenn Sie nach this pointer auf das Klassen-Level-Feld zugreifen würden, könnten Sie folgenden seltsamen Code erhalten:
was jemanden in die Irre führen könnte, dass wir tatsächlich verschiedene Eigenschaften oder Felder bearbeiten, aber wenn sie Zugriff auf den Klassennamen haben
%Vor%es ist klar, dass wir die gleiche Sache bearbeiten.
Auch im Speicher werden statische Felder an einem völlig anderen Ort (in der Nähe von Type object) gespeichert als Objektfelder, daher denke ich, dass es super klar ist.
Die eigentliche Frage ist - warum ist es kein Fehler in VB.NET? Ich würde vermuten, dass die Antwort ist, dass VB einige der alten .NET-VB-Funktionen erbte, die nicht sehr typsicher waren, und es ist ein seltsames Ergebnis einer solchen Vererbung.