
Zitat von
lizardking:
Ein Beispiel fuer ein Feature, was mich persoenlich stoeren wuerde. In Delphi saehe es ja so aus :
Delphi-Quellcode:
type
TFoo = public class
private
FProp: String;
public
property Prop : String read FProp write FProp;
end;
Du hast die Möglichkeit auch in Chrome. Sie macht nur wenig Sinn, da das Feld nur sinnlos in Editor und Code completion rumliegen würde.
In so einem Fall wird der Compiler _innerhalb_ der Klasse das Feld benutzen und zwar solange das Feld entweder implizit angelegt(wie in Christians Code) oder einfach einen inline setter hat (wie in deinem Code).
Zitat:
Wenn mich diese klare Trennung von Feldvariablen und Properties nicht sonderlich kuemmert, dann kann ich zur Not auch einfach die Variablen als public deklarieren

Da Chrome aber eine .Net Sprache ist, drehen sich die Räder ein wenig anders.
Zugriff auf Felder ist da mehr ein PITA: Class invariants können nicht bei Änderungen ablaufen, außerdem würde eine später eingefügte Property mit gleichem Typ & Namen einen breaking Change bedeuten (auf
IL Ebene[1]). Nicht zu vergessen, dass DataBinding nur auf Properties funktioniert.
Es gibt nur seeehr wenige Fälle, in denen man ein Feld öffentlich sichtbar machen sollte. Die meisten .Net Devs werden solch einen Fall wohl nie erleben.
Zitat:
Jetzt hab ich ein wenig mehr Code, wenn ich aber in der Klasse TFoo arbeite, weiss ich immer genau was passiert. Wenn ich dort naemlich "fremden" Code von Kollegen durchgehe, kann ich bei jeder Zuweisung erstmal nachschauen, ob nicht eine Setter-Methode noch mehr macht als nur die Variable zu setzen.
Für sowas gibt es in Object pascal interface sections, eine bessere Zusammenfassung einer Klasse wirst du so schnell nicht kriegen.
Zitat:
Wenn sich aber jeder daran haelt innerhalb der Klasse nur auf die Feldvariablen zuzugreifen, kann ich auf einen Blick ausschliessen, dass noch irgendwas sonst passiert.
Wenn sich jeder daran halten würde hättest du wirlich Pech. Du könntest keine Events auslösen auf die sich DataBinding registriert(siehe INotifyPropertyChange im .Net
SDK) oder die notwendig sind, damit andere Teile deiner App von dieser Änderung erfahren können. Deine Syntax oben benutze ich immer dann, wenn ich tatsächlich irgendwo direkt auf das Feld schreiben will oder wenn ich einen speziellen Setter implementieren will.
Da ich aber vorher schon die implizite Property stehen hatte ist das kein breaking Change mehr.[1]
[1]Es sind einfach ganz andere
IL OpCodes und Abläufe im Spiel ob man nun ldfld XXX oder call get_XXX auszuführt. -> Jede Assembly, die deine Binary benutzt wird definitv alle Viere von sich strecken wenn du von einem öffentlichen/protected Feld auf eine Property wechselst.
btw:@Daniel
Mit ein wenig Stolz kann ich von mir behaupten, dem unwiderstehlichen Drang, dem großen H einen Einlauf zu verpassen, erfolgreich widerstanden zu haben