Neue Sprachfeatures in Delphi?

[Codehunter]

Zitat von TiGü:

Zitat von Codehunter:

Ganz ehrlich? Inline-Variablendeklaration find ich ne Katastrophe. Leute die gewohnheitsmäßig "kryptografisch verschlüsselten" Code produzieren, werden ihre helle Freude haben. Und dann wenn es richtig schön verfrickelt ist und absolut keine Zeit zum Debugging da ist, dann landet sowas wieder bei mir... "Mach mal"...

Der neue Job macht Spaß?

Jeah! Den perfekten Job wirds eh nie geben. Aber die "Kryptografen" sind ganz angetan von meinem Easy-to-read-Code. Man wundert sich nur, warum man den viel schneller debuggen kann als den eigenen

Ich wünschte jedenfalls, man könnte solche neuen "Sprachfeatures" per Projekteinstellungen deaktivieren. Dann würde ich beim Projektleiter jedenfalls offene Türen einrennen....

[Ghostwalker]

Wie bei allen neuen Features gibts auch hier seine Vor-/Nachteile. Ich persönlich freu mich auf Inlines, da es mir an einigen Stellen die Arbeit erleichtert und den Code sogar einfacher lesbar macht.

Kommt halt drauf an, wie man das ganze dann verwendet.

Und, solange man Variablen und Typen deklarien muss, ist alles gut. Derbe wirds erst, wenn du Variablen mitten im Code einfach nutzt ohne Deklaration. Dann wirds erst wirklich interresant.

Mir gings bei den anonymen Methoden auch so, das ich davon nicht begeistert war. Wirklich nutzen tu ich sie eher selten. Aber mich stören sie auch nicht.

[Lemmy]

Zitat von Ghostwalker:

Kommt halt drauf an, wie man das ganze dann verwendet.

das ist richtig. Einen klaren Vorteil sehe ich bei den Schleifenvariablen - da sollte der Compiler nicht mit spielen, wenn man diese außerhalb der Schleife weiter nutzt, die aktuelle Warnung wird dann doch viel zu oft übersehen. Deklaration von Variablen ansonsten sehe ich kritisch, weil die unleserlichen Code noch mehr unleserlich machen. Auf der anderen Seite vielleicht auch ne Chance, den Anhängern von 10.000 LOC Methoden dann klar zu machen was ein Block ist, den man in eine separate Methode extrahieren kann...

[Uwe Raabe]

Zitat von Lemmy:

Einen klaren Vorteil sehe ich bei den Schleifenvariablen - da sollte der Compiler nicht mit spielen, wenn man diese außerhalb der Schleife weiter nutzt, die aktuelle Warnung wird dann doch viel zu oft übersehen.

Immerhin kannst du ja einstellen, daß hier anstatt einer Warnung ein Fehler gemeldet wird. Damit ließe sich solcher Code nicht compilieren.

[mkinzler]

Zitat von Lemmy:

Deklaration von Variablen ansonsten sehe ich kritisch, weil die unleserlichen Code noch mehr unleserlich machen.

Sehe ich auch so

Zitat von Lemmy:

Auf der anderen Seite vielleicht auch ne Chance, den Anhängern von 10.000 LOC Methoden dann klar zu machen was ein Block ist, den man in eine separate Methode extrahieren kann...

Ich befürchte nicht. Gerade dieses Klientel wird diese Feature so Nutzen, dass es zur weitereren Unleserlichkeit führen wird.

Es wird Delphi halt weiter an c angepasst.

Grundsätzlich ist es ja nicht schlecht, Features anderer Sprachen zu übernehmen. Diese "Übernahme" sehe ich aber als Verschlechterung ( nicht für Schleifenvariablen, die ist sinnvoll).

[Sherlock]

Delphi ist am Ende halt doch ein Pascal. Ich sehe daher keinen Zwang, (Un)Möglichkeiten anderer Sprachfamilien hinein panschen zu müssen. Das betrifft jetzt nicht Paradigmen wie Objektorientierung, aber Inline Deklaration, wozu? Wer ernsthaft Methoden hat die sooo lang sind, daß er nicht einfach nur im Code Editor vor das begin klicken kann, um dort eben schnell die Deklaration einzufügen, und dennoch seine eigentlich bearbeitete Codestelle sieht, der hat ein Problem, daß er mit Inlinedeklarationen bestenfalls verschlimmert. Mit Shift+Ctrl+V muss man nicht mal das begin im Blick haben.

Sherlock

[TiGü]

Meine Güte, ist das wieder ein Jammern auf hohem Niveau!

Ihr müsst die neuen Sprachfeatures nicht nutzen!

Am Ende ist es eine Gewohnheitssache.
An so Teufelszeug wie Generics, Anonyme Methoden oder vereinfachte Arraybehandlung ist eurer Quelltext auch nicht gestorben, oder?

[Codehunter]

Zitat von TiGü:

Ihr müsst die neuen Sprachfeatures nicht nutzen!

Am Ende ist es eine Gewohnheitssache.

Letztlich ja doch, wenn im Team einer damit anfängt müssen zwangsläufig alle anderen auch. Spätestens beim Entkäfern wenn der Kollege im Urlaub ist.

Zitat von TiGü:

An so Teufelszeug wie Generics, Anonyme Methoden oder vereinfachte Arraybehandlung ist eurer Quelltext auch nicht gestorben, oder?

Hmm ja, wenns denn richtig funktionieren würde... Aber dann sind wir ganz schnell wieder bei der Pro-Kontra-Diskussion "Featuritis vs. Stabilität"

[Schokohase]

Zitat von Sherlock:

Delphi ist am Ende halt doch ein Pascal. Ich sehe daher keinen Zwang, (Un)Möglichkeiten anderer Sprachfamilien hinein panschen zu müssen.

Es muss aber eine gewisse Menge an Delphi-Programmierern gegeben haben, die sich dieses Feature gewünscht haben.

So wie du ausschließlich die Nachteile siehst, sehen andere eben nur die Vorteile.

Der Eine sieht in Feuer Gefahr und der Andere Behaglichkeit.

Hier ein Beispiel wo diese Inlines den Code besser lesbarer machen:

Delphi-Quellcode:

{ Das funktioniert so nicht, denn es wird nur 10 ausgegeben }

procedure TaskTest1( );
var
  i:     Integer;
  tasks: TArray<ITask>;
  o:     TObject;
begin
  Writeln( 'TaskTest1' );
  o := TObject.Create;
  try
    SetLength( tasks, 10 );
    for i := 0 to 9 do
      begin
        tasks[i] := TTask.Run(
            procedure
          begin
            TMonitor.Enter( o );
            try
              Writeln( i );
            finally
              TMonitor.Exit( o );
            end;
          end );
      end;
    TTask.WaitForAll( tasks );
  finally
    o.Free;
  end;
end;

{ Das muss man aktuell so schreiben }

function BuildTask( i: Integer; const o: TObject ): ITask;
begin
  Result := TTask.Run(
    procedure
    begin
      TMonitor.Enter( o );
      try
        Writeln( i );
      finally
        TMonitor.Exit( o );
      end;
    end );
end;

procedure TaskTest2( );
var
  i:     Integer;
  tasks: TArray<ITask>;
  o:     TObject;
begin
  Writeln( 'TaskTest2' );
  o := TObject.Create;
  try
    SetLength( tasks, 10 );
    for i := 0 to 9 do
      begin
        tasks[i] := BuildTask( i, o );
      end;
    TTask.WaitForAll( tasks );
  finally
    o.Free;
  end;
end;

{ Oder mit den Inlines geht es eben so }

procedure TaskTest3( );
var
  i:     Integer;
  tasks: TArray<ITask>;
  o:     TObject;
begin
  Writeln( 'TaskTest1' );
  o := TObject.Create;
  try
    SetLength( tasks, 10 );
    for i := 0 to 9 do
      begin

        var val := i;

        tasks[i] := TTask.Run(
            procedure
          begin
            TMonitor.Enter( o );
            try
              Writeln( val );
            finally
              TMonitor.Exit( o );
            end;
          end );
      end;
    TTask.WaitForAll( tasks );
  finally
    o.Free;
  end;
end;

[mkinzler]

Ja es gibt viele, die sich das gewünscht haben.

Es gibt auf FB und G++ ja diverse Wunschlisten für neue Features. Dieses stand ganz oben. Aber nur weil viele ein Feature wünschen, ist es noch nicht sinnvoll:
Ein weiteres Feature, dass sich viele wünschen ist die Ersetzung von begin..end mit

Code:

{}

.