Träume, Wünsche und Wahnvorstellungen...

[DeddyH]

Na gut, wenn schon with, dann aber eins ohne Verwechslungsgefahr. Ich bin beileibe kein Freund von Basic, aber dort ist das eindeutig besser gelöst: ein Punkt vor der Property kennzeichnet, dass es sich um das mit with verbundene Objekt handelt.

[Elvis]

Zitat von DeddyH:

Na gut, wenn schon with, dann aber eins ohne Verwechslungsgefahr. Ich bin beileibe kein Freund von Basic, aber dort ist das eindeutig besser gelöst: ein Punkt vor der Property kennzeichnet, dass es sich um das mit with verbundene Objekt handelt.

Und Imp schlug vor es so wie in Oxygene zu machen. Dann gibt es keinen komischen Punkt, sondern einen richtigen Bezeichner.

In dem Kontext wäre natürlich auch Oxygenes "using" angebracht, und dass man eine richtige Syntax für Konstruktoren bekommt. (Nicht diesen komischen Krams in dem jeder seinen Ctor nennen kann wie er will und im Code sieht's aus wie eine statische Methode)
"Using" wäre dann wie Imps "with" aber würde ein try-finally erzeugen und am Ende Free ausführen.

Delphi-Quellcode:

procedure SomeClass.Miep;
begin
  using trööt := new TStringList() do
  begin
    trööt.Add('abc');
    trööt.Xyz();
  end;
end;

Aber all das ist komplett witzos in dem Babelcode, den Delphi momentan darstellt. Delphi braucht einen clean-slate, ein Delphi 2.0, um ohne den Turbo Pascal Krempel weitermachen zu können.
Was bringen einem solche Features, und der Großteil des Codes, den man anschauen muss sieht immer noch so abscheulich aus?

[Robotiker]

Zitat von Elvis:

Aber all das ist komplett witzos in dem Babelcode, den Delphi momentan darstellt. Delphi braucht einen clean-slate, ein Delphi 2.0, um ohne den Turbo Pascal Krempel weitermachen zu können.

Hm, ich glaube eher nicht, das die Mehrzahl der Delphi Entwickler damit einverstanden wäre.

Im übrigen geht das mit der VCL schon seit über 10 Jahren

Code:

void __fastcall TForm1::Button1Click(TObject *Sender)
{
  auto_ptr<TStringList> foo(new TStringList);

  foo->Add("trööt");

  // Und automatisch weg ist die Stringlist ...
}

In C++ gibt es RAII, das ist viel besser als dieses using aus C#.
http://de.wikipedia.org/wiki/RAII

[implementation]

Zitat von Elvis:

dass man eine richtige Syntax für Konstruktoren bekommt. (Nicht diesen komischen Krams in dem jeder seinen Ctor nennen kann wie er will und im Code sieht's aus wie eine statische Methode)

Also gerade die benannten Konstruktoren empfinde ich als einen Vorteil von Pascal gegenüber den C-Sprachen.
Ganz einfach, weil du so mehrere Konstruktoren haben kannst, z.B.:

Delphi-Quellcode:

constructor Create(const s: string);
constructor CreateFmt(const s: string; const args: array of const);
constructor CreateFromFile(const filename: string);

Klar, CreateFmt und CreateFromFile ließen sich als Klassenfunktionen deklarieren, aber was findest du verwirrender:

• 3 Konstruktoren, die zum Erstellen einer Instanz sind
• 1 Konstruktor, sowie 2 Klassenmethoden, die die Aufgabe von Konstruktoren übernehmen

Das Erstellen von Instanzen ist Konstruktorensache, es dann in Klassenmethoden auszulagern und ihnen eine andere Syntax zu geben als dem Konstruktor halte ich für unsauber.
Vergleiche bitte mal:

Delphi-Quellcode:

// schön
x := TKlasse.Create(..);
x := TKlasse.CreateFmt(..);
x := TKlasse.CreateFromFile(..);

// hässlich
x := new TKlasse(..);
x := TKlasse.CreateFmt(..);
x := TKlasse.CreateFromFile(..);

[implementation]

Zitat von Elvis:

und im Code sieht's aus wie eine statische Methode

Glücklicherweise gibt's in Delphi ja Klassenmethoden statt statische.
Hier wird noch heimlich ein Klassenzeiger (dass es die überhaupt gibt ist eine weitere Stärke) übergeben.
Der Vorteil: Klassenmethoden können dadurch virtuell sein und überschrieben werden


Ich habe eine Zeit lang nur mit C# programmiert.
Mir haben viele Features davon sehr gefallen, aber manches habe ich vermisst:

• Klassenzeiger, und damit verbunden auch virtuelle Klassen-/ statische Methoden
• Vernünftige Konstruktoren, die sind in C# nämlich nur Schrott:
  • nicht benennbar und
  • werden nicht vererbt
• Die Tatsache, dass array[a][b] = array[a,b] ist
• Mengen

Dies sind Dinge, die ich bisher nur aus Delphi kenne und die bitte auf gar keinen Fall abgeschafft gehören.

[himitsu]

Man sollte ienfach unterbinden, daß man Konstruktoren nur noch über Typen aufrufen kann und nicht über Objekte (bzw. daß es eine Compiler-Warnung gibt)
und schon ist das Problem behoben, was vorallem viele Anfänger haben, welche Variable.Create; anstatt von Variable := Typ.Create; aufrufen.

[Namenloser]

Also ich finde die Konstruktor-Variante unter Delphi eigentlich von allen Sprachen so mit am elegantesten, und zwar gerade weil der Konstruktor aussieht wie eine Klassenmethode. Passt doch super ins objektorientierte Schema: Die Klasse ist selbst dafür zuständig, eine Instanz von sich zu erzeugen.

Und dass man mehrere Konstruktoren haben kann, finde ich auch ein nettes Feature. Wer seinen Standard-Konstruktor anders nennt als Create ist imo selbst schuld... dass z.B. eigene Typen mit dem Präfix T beginnen schreibt Delphi ja auch nicht explizit vor, aber es ist die gängige Konvention.

[implementation]

Zitat von NamenLozer:

Wer seinen Standard-Konstruktor anders nennt als Create ist imo selbst schuld...

Im FPC gibt's eine Kommandozeilenoption, die auslöst, dass alle Konstruktoren Init und alle Destruktoren Done heißen müssen, sonst gibt's eine Fehlermeldung.
Die Option hab ich irgendwie mal in 'nen Projekt reingekriegt, und deshalb heißen da jetzt alle meine Konstruktoren und Destruktoren Init und Done

[edit]
Laut diesem Dokument muss das wohl -Ss gewesen sein:

Code:

-Ss        Constructor name must be init (destructor must be done)

[himitsu]

Zu den Build-Ereignissen hätte ich auch gerne noch etwas Post-Build-Ähnliches, welches nach einem erfolglosem Compilierungsversuch ausgeführt wird.

[mkinzler]

Konstruktoren sind aber auch Klassenmethoden. Ruft man sie später direkt auf einen Objek auf, werden diese erneut ausgeführt, ohne dass eine neue Instanz erzeugt wid