[Chrome] Der Blick über den Tellerrand

[Daniel]

@Hansa & Frickeldrecktuxer_TM: Gleich sperre ich euch beide aus diesem Thread aus.



Meine Güte - seit Jahren knallt Ihr beiden immer wieder aneinander und lernt nichts daraus. Wieviele Threads habt Ihr beiden mit Euren kindischen Kleinkriegen bereits zerstört? Ist das Geltungsbewusstsein tatsächlich so groß, dass die sachliche Diskussion egal ist? Wenn dies der Fall ist, solltest Du über Konsequenzen nachdenken.

Ich werde beide Beiträge gleich deaktivieren und bitte darum, diese Diskussion sachlich fortzuführen.


[edit]
Mal sehen, vielleicht geht's ja auch ohne deaktivieren.

@Rest: Bitte ignoriert die beiden.
[/edit]

[edit=alcaeus]Name korrigiert Mfg, alcaeus[/edit]

[Elvis]

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

[Daniel]

Zitat von Elvis:

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

Das habe ich freudig zur Kenntnis genommen.

[SubData]

Zitat von Christian S.:

Aber irgendwann ist man aus dem Stadium heraus, dass man einen Compiler braucht, der einem Vorschriften macht, um lesbaren Code zu erzeugen.

Für mich hört sich das an, wie: Irgendwann kann man auch sauberen Code schreiben, ohne dass einem der Compiler dabei helfen muss ^^

[MrSpock]

Hallo SubData,

ja, die Aussage hört sich so an. Ich glaube nur einfach nicht daran. Die Disziplin wird in der Regel leider nur von sehr wenigen Programmierern eingehalten. Tools, die die Disziplin "fordern" -und dazu zählen auch Compiler- sind deshalb sinnvoll. Gute Programmierer werden häufig als Programmierer betrachtet, die schnell funktionierenden Code erstellen. Der Grad der Einhaltung von Regeln wird dabei häufig nur am Rand betrachtet.

Von daher ist ein Blick über den Tellerrand ja durchaus angebracht. Man sollte aber wirklich die Vorteile und die Nachteile auch gerade bezüglich der Wartbarkeit des entstehenden Codes sorgfältig gegeneinander abwägen. Sollte nach einem solchen Prozess die Vorteile z.B. von Chrome überwiegen, dann sollte man sich dafür entscheiden, sonst dagegen. Ein Blick über den Tellerrand hat sich dann in jedem Fall gelohnt, entweder zur Bestätigung des bisherigen Tools, oder aber zur Auswahl eines neuen.

[Daniel G]

Zitat von MrSpock:

Gute Programmierer werden häufig als Programmierer betrachtet, die schnell funktionierenden Code erstellen.

Dann bleibe ich lieber ein "schlechter Programmierer", wenn im Gegenzug die Leute kapieren, was ich mir da zusammengeschrieben habe.
Bilde ich mir das eigentlich nur ein, oder ist die Chrome - IDE deutlich günstiger als die Delphi - IDE? (um jetzt mal auf einen ökonomischen Punkt zu kommen... )

[Elvis]

Zitat von Daniel G:

Bilde ich mir das eigentlich nur ein, oder ist die Chrome - IDE deutlich günstiger als die Delphi - IDE? (um jetzt mal auf einen ökonomischen Punkt zu kommen... )

Wo hast du eine Chrome IDE gesehen?
Chrome selbst kostet für Ex-(.Net-)Delphianer 150€, dazu kommt noch ein VS05 Standard mit nochmal 300€ (keine Express, da die keine AddIns laden können).
Chrome ist also eine weitere Sprache im VS, es hat keine IDE.

[mkinzler]

Zitat:

Bilde ich mir das eigentlich nur ein, oder ist die Chrome - IDE deutlich günstiger als die Delphi - IDE? (um jetzt mal auf einen ökonomischen Punkt zu kommen... Zwinkern )

Die CLI-Edition kosten sogar nix. Aber da Chrome keine eigene IDE hat muß man hier noch die KKosten von VS2005 hinzurechnen. Mit der express löüft Chrome nicht. (zumindest nicht die Trial-Version)

[Elvis]

Zitat von mkinzler:

Zitat:

Bilde ich mir das eigentlich nur ein, oder ist die Chrome - IDE deutlich günstiger als die Delphi - IDE? (um jetzt mal auf einen ökonomischen Punkt zu kommen... Zwinkern )

Die CLI-Edition kosten sogar nix.

Dürfen auch nix kosten. Sonst würden einige mit ihren ASPX Spieereien große Probleme kriegen.
Der IIS/Cassini/Apache braucht schon einen CodeDOM/Compiler um Codebehind und inline Code verweben zu können. (Wobei man das auch statisch kompiliert lösen kann/sollte)

Deshalb sieht man bei Delphi.Net ASPX-Dateien language="C#"

[Christian S.]

Zitat von MrSpock:

ja, die Aussage hört sich so an. Ich glaube nur einfach nicht daran. Die Disziplin wird in der Regel leider nur von sehr wenigen Programmierern eingehalten.

Da ich als Hobby-Programmierer meist alleine arbeite, ist das ein Punkt, der für mich kaum von Belang ist, weil ich weiß, dass ich die Disziplin habe. Plant man die Anschaffung eines Compilers für eine große Gruppe (z.B. in einer Firma), ist das sicherlich ein Punkt, den man bedenken muss. (Unabhängig davon, wie meine Einschätzung davon ist, das ist auch nicht so wichtig.)

Zitat von MrSpock:

Von daher ist ein Blick über den Tellerrand ja durchaus angebracht. Man sollte aber wirklich die Vorteile und die Nachteile auch gerade bezüglich der Wartbarkeit des entstehenden Codes sorgfältig gegeneinander abwägen. Sollte nach einem solchen Prozess die Vorteile z.B. von Chrome überwiegen, dann sollte man sich dafür entscheiden, sonst dagegen. Ein Blick über den Tellerrand hat sich dann in jedem Fall gelohnt, entweder zur Bestätigung des bisherigen Tools, oder aber zur Auswahl eines neuen.

@Preis für IDE: Insgesamt kommt man aber immer noch deutlich günstiger weg als bei Delphi. Man hat zwar dann auch die anderen Delphi-Personalities nicht, dafür sind andere Dinge mit im Paket. Muss man halt schauen, was man braucht