Neue Sprachfeatures in Delphi?

[TiGü]

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

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?

[Schokohase]

Zitat:

Zitat von Sherlock (Beitrag 1416624)

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

Delphi-Quellcode:

begin..end

mit

Code:

{}

.

[Ralf Kaiser]

Zitat:

Zitat von mkinzler (Beitrag 1416631)

Ein weiteres Feature, dass sich viele wünschen ist die Ersetzung von

Delphi-Quellcode:

begin..end

mit

Code:

{}

.

Er hat Jehova gesagt. Steinigt ihn! :twisted:

[Schokohase]

Zitat:

Zitat von mkinzler (Beitrag 1416631)

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

Delphi-Quellcode:

begin..end

mit

Code:

{}

.

Allerdings unterscheiden sich beide Anforderungen doch erheblich. Die Inlines können nachweislich (s.o.) helfen den Code schlanker und übersichtlicher zu halten. (*)

Diese Ersetzung von

Delphi-Quellcode:

begin .. end

kann dieses (soweit ich das sehe) nicht liefern.

Darum wurden wohl auch die Inlines realisiert (es gibt einen konkreten Nutzen ohne den alten Code zu brechen) und die

Delphi-Quellcode:

{}

eben nicht.

(*) Ja, mit einem Hammer kann man ganz toll Nägel in die Wand kloppen oder sich lebensgefährlich verletzen. Ist der Hammer also jetzt nützlich oder gefährlich?

[Uwe Raabe]

Zumindest kann man mit einer Inline-Variablendeklaration auch eine lokale Variable initialisieren (muss dann noch nicht mal eine Konstante sein!). Das geht bisher so jedenfalls nicht ohne mindestens eine zusätzliche Zeile Code.

[mkinzler]

Die Initialisierung bei der Deklaraion und die Verwendung von scoped Variablen für Schleifen ist positiv.
Aber die freie Dekalarationsmöglichkeit im Text (anstatt in der Var-Sektion) finde ich eher negativ.

[Codehunter]

Zitat:

Zitat von TiGü (Beitrag 1416628)

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:

Zitat von TiGü (Beitrag 1416628)

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"

[bytecook]

Zitat:

Zitat von Codehunter (Beitrag 1416645)

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.

Warum denk ich da jetzt urplötzlich an MySatan Roundup zum DeBeetlen? :twisted:
Naja, mal abwarten was wirklich kommt...

[Codehunter]

Zitat:

Zitat von bytecook (Beitrag 1416646)

Zitat:

Zitat von Codehunter (Beitrag 1416645)

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.

Warum denk ich da jetzt urplötzlich an MySatan Roundup zum DeBeetlen? :twisted:

Da verwechselst du was. Roundup entkäfert nicht. Höchstens indirekt weils Käfergetier nix mehr zu futtern findet. 8-)

Zitat:

Zitat von bytecook (Beitrag 1416646)

Naja, mal abwarten was wirklich kommt...

Das denke ich auch. Die ganze Aktion kommt mir doch sehr seltsam vor. Inoffizielle Kanälen ist nicht unbedingt zu trauen. Wer weiß, wir machen uns hier verrückt und dann wars nur ein Sturm im Wasserglas.

[mkinzler]

Zitat:

Wer weiß, wir machen uns hier verrückt und dann wars nur ein Sturm im Wasserglas.

Normalerweise kommt ein Dementi seitens EMBT recht schnell. Es scheit sich ja um eine öffentliche Veranstaltung mit EMBT-Mitarbeitern gehandelt zu haben.

[Codehunter]

Zitat:

Zitat von mkinzler (Beitrag 1416651)

Zitat:

Wer weiß, wir machen uns hier verrückt und dann wars nur ein Sturm im Wasserglas.

Normalerweise kommt ein Dementi seitens EMBT recht schnell. Es scheit sich ja um eine öffentliche Veranstaltung mit EMBT-Mitarbeitern gehandelt zu haben.

Warum nur wünscht ich mir hier zum ersten Mal ein Dementi seitens Emba? :lol:

[mkinzler]

Zumindest ein halbes ;)

[Codehunter]

Zitat:

Zitat von Uwe Raabe (Beitrag 1416616)

Zitat:

Zitat von Codehunter (Beitrag 1416611)

Ich wünschte jedenfalls, man könnte solche neuen "Sprachfeatures" per Projekteinstellungen deaktivieren.

Ich hätte das viel lieber für einige ältere...

Oder generell Sprachfeatures per Projekteinstellungen abwählbar. Das Problem wird nur sein, dass das gar nicht geht weil einem dann ratzfatz die VCL, FMX etc. vorn über kippt weil Emba davon reichlich Gebrauch macht. Sowohl neuere als auch ältere Sprachfeatures. Wenn dann projektlokal über Compilerswitches in den .dpr/dpk

[mkinzler]

Man könnte auch einfach eine ältere Delphiversion einsetzen ...

:mrgreen:

[Zacherl]

Für mich sind Inline Variablen ganz und gar nicht gleichzusetzen mit geringerer Übersicht und Chaos. Ganz im Gegenteil! Was hier oft vergessen wird, ist dass die Variablen an ein Scope gebunden sind. Also nur valide sind im Block in dem sie auch definiert wurden.
Kenne das von C++, wo man coole Sachen machen kann (weil dort auch Objekte automatisch den Destructor aufrufen, wenn die Instanz aus dem Scope läuft). Unter Delphi wird man hier mit Interfaces ähnliche Magie betreiben können.

Jeder kennt so Funktionen, bei denen die Zählervariablen schon bei N oder weiter angelangt sind, oder generell der Variablenblock 10-20 Einträge hat. Oft ist das natürlich schlechtes Design, aber oft lassen sich diese Funktionen auch nicht gescheit aufteilen. Hier werden Inline Variablen die Übersicht deutlich erhöhen. Anderseits muss man natürlich ggfls. auch etwas suchen, bevor man die Deklaration findet - wobei die IDE hierfür ja Shortcuts hat.

Also im Grunde wie schon erwähnt: Hat alles seine Vor- und Nachteile.

[bernau]

Zitat:

Zitat von Codehunter (Beitrag 1416645)

Zitat:

Zitat von TiGü (Beitrag 1416628)

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.

Gib es für so etwas keine Teamguidelines? Ein klares "Das darf verwendet werden", "Das darf nicht verwendet werde" sollte doch möglich sein.

Die nächste Stufe wäre dann, dass jeder ohne nachzufragen seine eigenen Komponenten verwendet.

[Frickler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1416638)

Zumindest kann man mit einer Inline-Variablendeklaration auch eine lokale Variable initialisieren (muss dann noch nicht mal eine Konstante sein!). Das geht bisher so jedenfalls nicht ohne mindestens eine zusätzliche Zeile Code.

Sehe ich das aber richtig, dass das nicht so geht (wie bei globalen Variablen):

Delphi-Quellcode:

procedure Bla;
var x: integer = 3;
begin
  ...
end;

sondern halt so:

Delphi-Quellcode:

procedure Bla;
begin
  var x: integer := 3;
  ...
end;

...also noch ne neue Süntacks?

[Uwe Raabe]

Zitat:

Zitat von bernau (Beitrag 1416658)

Gib es für so etwas keine Teamguidelines? Ein klares "Das darf verwendet werden", "Das darf nicht verwendet werde" sollte doch möglich sein.

Das sehe ich auch so. Wenn es noch nicht mal einen einheitlichen Coding-Style innerhalb einer Firma oder eines Teams gibt, dann hat man doch schon ganz andere Probleme.

[Uwe Raabe]

Zitat:

Zitat von Frickler (Beitrag 1416660)

...also noch ne neue Süntacks?

Genau darum geht es in diesem Thread ja.

[Codehunter]

Zitat:

Zitat von Uwe Raabe (Beitrag 1416661)

Zitat:

Zitat von bernau (Beitrag 1416658)

Gib es für so etwas keine Teamguidelines? Ein klares "Das darf verwendet werden", "Das darf nicht verwendet werde" sollte doch möglich sein.

Das sehe ich auch so. Wenn es noch nicht mal einen einheitlichen Coding-Style innerhalb einer Firma oder eines Teams gibt, dann hat man doch schon ganz andere Probleme.

Einheitlicher Coding-Style kommt hier ganz automatisch, mit STRG-D :-D Wenn ich mich irgendwann mal ein bissi hochgearbeitet habe in der Hackordnung (Vorsicht, Wortspiel! *gg*) würd ich dich ja gerne mal einladen als Referent. Wie lang hast du noch bis zur Rente? :-D Aber immerhin, mit MMX jetzt schon auf der Jagd nach zirkulären Referenzen. Davon 198 in einer einzigen Unit, nur um in einer anderen Unit eine einzige Boolean zu ändern ^^

Ok, </OT> sonst klaut mir der Daniel noch die Flinte und macht Jagd auf mich :-)

[Codehunter]

Zitat:

Zitat von Frickler (Beitrag 1416660)

Sehe ich das aber richtig, dass das nicht so geht (wie bei globalen Variablen):

Delphi-Quellcode:

procedure Bla;
var x: integer = 3;
begin
  ...
end;

sondern halt so:

Delphi-Quellcode:

procedure Bla;
begin
  var x: integer := 3;
  ...
end;

...also noch ne neue Süntacks?

Woooha... Ich seh vor meinem geistigen Auge schon sowas:

Delphi-Quellcode:

function Produce: Integer;
var
  I: Integer;

  procedure SubProduce;
  var
    I: Integer;

    procedure SubSubProduce;
    begin
      for var I: Integer = 0 to 3 do begin
        // Irgendwas
      end;
      Inc(I, 17);
    end;

  begin
    Inc(I, 22);
  end;

begin
  Inc(I, 1234);
  Result := I;
end;

Bei so viel Scope braucht man bald ein Periscope :-D

[Frickler]

Endlich eine handliche Ablösung für "with":
Statt

Delphi-Quellcode:

var cds: TClientDataSet; qry: TUniQuery;
begin
  cds := Datamodule.cds_Report;
  qry := Datamodule.qry_Sales;
  // ...viel Text...
  cds.FieldByName('bla').AsString := qry.FieldByName('bla').AsString;

schreiben wir jetzt

Delphi-Quellcode:

// ...viel Text...
begin
  var cds := Datamodule.cds_Report;
  var qry := Datamodule.qry_Sales;
  cds.FieldByName('bla').AsString := qry.FieldByName('bla').AsString;
  ...
end;

P.S.: ja, man kann auch

Delphi-Quellcode:

Datamodule.cds_Report.FieldByName('bla').AsString := Datamodule.qry_Sales.FieldByName('bla').AsString;

schreiben. Breitbildschirm sei dank. Aber es gibt auch tiefer verschachtelte Fälle, und irgendwann wirds ziemlich unübersichtlich.

[Codehunter]

Wenn mans genau nimmt würde der

Delphi-Quellcode:

var

-Block zwischen

Delphi-Quellcode:

procedure

und

Delphi-Quellcode:

begin

nunmehr beinahe obsolete. Das kann doch nicht im Sinne des Erfinders sein.

[Frickler]

Zitat:

Zitat von Codehunter (Beitrag 1416670)

Wenn mans genau nimmt würde der

Delphi-Quellcode:

var

-Block zwischen

Delphi-Quellcode:

procedure

und

Delphi-Quellcode:

begin

nunmehr beinahe obsolete. Das kann doch nicht im Sinne des Erfinders sein.

Wenn sie auf Zack sind, ist es "deprecated" mit (abschaltbarer) Compilerwarnung.

[stahli]

Ich finde die Ideen gut und hilfreich.

Variablen dort zu deklarieren, wo sie gebraucht werden, finde ich sinnvoll.
Wer will, kann sie ja direkt am Prozerduranfang deklarieren (oder optional vor dem "begin").

Auch einfach einen Alias für längere Variablennamen oder Member (var C = x.y.z.a.b.c;) definieren zu können, finde ich gut.

Beides habe ich auch für meine Scriptsprache vorgesehen, an der ich bastle.

Ich finde das nicht kryptisch sondern übersichtlich.
Wichtig ist, dass Variablen vor der Verwendung deklariert werden müssen.


@Codehunter

Das Problem mit dem Scope von Inline-Prozeduren hat man ja jetzt auch schon. Nur die Verwendung von I in Schleifen wird jetzt halt abgelehnt.

[Neutral General]

Zitat:

Zitat von stahli (Beitrag 1416672)

Beides habe ich auch für meine Scriptsprache vorgesehen, an der ich bastle.

Oha interessant. Kannst du was über die Sprache erzählen oder mal ein Codebeispiel posten?
Würde mich mal interessieren :)

[stahli]

[OT]
Ja, schreib mich mal per eMail an, dann schicke ich heute Abend etwas (Video)...
[/OT]

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1416665)

Einheitlicher Coding-Style kommt hier ganz automatisch, mit STRG-D

Eine einheitliche Formatierung ist aber bei weitem noch kein einheitlicher Coding-Style. 8-)

Zitat:

Zitat von Codehunter (Beitrag 1416665)

Wie lang hast du noch bis zur Rente?

Bis zu was? :-D

[DieDolly]

Zitat:

Auch einfach einen Alias für längere Variablennamen oder Member (var C = x.y.z.a.b.c definieren zu können, finde ich gut.

Habe ich irgendwo etwas übersehen?
Das wäre toll, wenn das wirklich bald möglich sein sollte.
Aber die Codevervollständigung muss da auch mit zurecht kommen sonst bringt das nix. Bis heute kommt die Codevervollständigung auch nicht mit Unitnamen wie Meine.Utils.pas zurecht.

[sakura]

Zitat:

Zitat von DieDolly (Beitrag 1416679)

Bis heute kommt die Codevervollständigung auch nicht mit Unitnamen wie Meine.Utils.pas zurecht.

Ich nutze das seit Jahren ohne Probleme :gruebel:

...:cat:...

[Schokohase]

Zitat:

Zitat von Codehunter (Beitrag 1416667)

Woooha... Ich seh vor meinem geistigen Auge schon sowas:

Delphi-Quellcode:

function Produce: Integer;
var
  I: Integer;

  procedure SubProduce;
  var
    I: Integer;

    procedure SubSubProduce;
    begin
      for var I: Integer = 0 to 3 do begin
        // Irgendwas
      end;
      Inc(I, 17);
    end;

  begin
    Inc(I, 22);
  end;

begin
  Inc(I, 1234);
  Result := I;
end;

Bei so viel Scope braucht man bald ein Periscope :-D

Wenn du das ohne die Inlines schreibst, würdest du den Code dann toll finden?

Nein, der wäre auch einfach nur grottenschlecht. Merke: Inlines machen schlechten Code nicht besser.

[DieDolly]

Zitat:

Zitat von sakura (Beitrag 1416680)

Zitat:

Zitat von DieDolly (Beitrag 1416679)

Bis heute kommt die Codevervollständigung auch nicht mit Unitnamen wie Meine.Utils.pas zurecht.

Ich nutze das seit Jahren ohne Probleme :gruebel:

...:cat:...

Sicher?

Delphi-Quellcode:

unit Meine.Utils;

interface

uses
 Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
 Vcl.Controls, Vcl.Forms, Vcl.Dialogs;

type
 TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
 private
  {Private-Deklarationen}
 public
  {Public-Deklarationen}
 end;

function Test(AParam: Integer): Boolean;

var
 Form1: TForm1;

implementation

{$R *.dfm}

function Test(AParam: Integer): Boolean;
begin
 Result := AParam = 1;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
 Meine.Utils.Test( ... )
end;

end.

Wenn du im FormCreate Meine eingibst. Poppt dann Meine.Utils(. etc) auf?

[Bernhard Geyer]

Zitat:

Zitat von Zacherl (Beitrag 1416657)

Für mich sind Inline Variablen ganz und gar nicht gleichzusetzen mit geringerer Übersicht und Chaos. Ganz im Gegenteil! Was hier oft vergessen wird, ist dass die Variablen an ein Scope gebunden sind. Also nur valide sind im Block in dem sie auch definiert wurden.

:thumb:
Hatter erst vor wenigen Tagen einen Fall bei dem eine Scope-Sichtbare Variable den Fehler vermieten hätte (Reuse von Methoden-Globalen Variablen)

[stahli]

[etwas OT "Finden von Units"]
Bei meinem XE3 funktioniert das wie ein Blinklicht: geht - geht nicht - geht - geht nicht...
Aber das liegt m.E. nicht an den Punkten. Die IDE kennt einfach mehrere Units nicht - auch nicht wenn man mit Ctrl auf eine Funktion o.ä. klickt oder eine Unit mit Ctrl-A sucht.
Ich suche dann in der Hilfe, in welche Unit die betreffende Funktion wohl gehört. :-(

@DieDolly
Testen könnte ich Deinen Versuch erst heute Abend.
[/etwas OT]

[sakura]

Zitat:

Zitat von DieDolly (Beitrag 1416682)

Wenn du im FormCreate Meine eingibst. Poppt dann Meine.Utils(. etc) auf?

Ja.

...:cat:...

[sakura]

Mal zum eigentlichen Thema:

• Inline-Variablen: Gut, gerade Schleifenvariablen sind praktisch
• ARC-Remove: An und für sich gut, da der sehr langsam war, allerdings schlecht für bestehenden Code, in welchem sich der Entwickler darauf verlassen hat

...:cat:...

[Schokohase]

Zitat:

Zitat von sakura (Beitrag 1416691)

ARC-Remove: An und für sich gut, da der sehr langsam war, allerdings schlecht für bestehenden Code, in welchem sich der Entwickler darauf verlassen hat

Es war halt gut gedacht, schlecht gemacht und darum nicht in Gänze durchsetzbar Reasons: ... Cannot move VCL to ARC.

[mkinzler]

Zitat:

Cannot move VCL to ARC

Komischerweise funktioniert diese aber bei VclLinux unter Linux.

[MichaelT]

Es gibt praktisch keine Alternative zwischen vor dem äußersten Codeblock oder irgendwo. Es ist in PL/SQL teils überraschend wenn mitten im Programmfluss ein DECLARE daherkommt. In Modula II waren die geschachtelten Module noch exzessiver, deswegen hat diese Form der Schachtelung sich nicht verbreitet.

Damit verbleibt die C Variante - überall erlaubt und per Konvention beschränkt.

{
Variablendaklaration /*blendet gleichnamige aus den Umschließenden Blöcken aus */
} /* Sichtbarkeit der Variable endet hier */

Damit klopfen die Global im Einzelfall aus dem Motiv. Damit man auf den Wert gespeichert in einer Variable deklariert und definiert in einem äußeren Block kann zurückgreifen ...

Bis vor 15 Jahren kann man sagen, dass Objekte tragende Säulen einer Implementierung waren und Hilfsvariablen als solche benamt erkennbar waren und zumeist Fundamentaldatentypen. Das ändert sich zusehends. Die Verwendung von Interfaces usw...

Jetzt stellt sich die Frage. Was außer einer Deklaration nahe der Verwendung bleibt als Alternative und wie kann ich mir in einer Sprache die eine Konstruktoraufruf voraussetzt im Regelfall bei der endgültigen Verwendung im Rahmen der Anwendung mir die Typenangabe ala

TMyType myObj = new TMyType();

sparen und man landet bei

var myObj = new TMyType;

--

Mir var ist es nicht getan. Der Minimalfall ist an sich das Iteratorobjekt.

--

Das Thema, da stimme ich zu, ist so ausbaufähig, dass selbst schön geschriebener Code unlesbar wird oder nurmehr für jene die wissen was der Code eigentlich bedeutet. Ala APL :-D als der Paradevertreter einer Write Only Language.

--

Der Zug der Zeit tuckert bezüglich solcher Sprachfeatures selbst an ABAP nicht vorbei.

statt:
DATA: lv_vehicle TYPE string.
lv_vehicle = 'Mercedes'.

ab ABAP 7.4

DATA(lv_vehicle) = 'Mercedes'.

(kopiert vom Netz)

In dem Artikel sind noch andere echte Gustostückerl.

---

Ich bin auch mehr der Fan von Selektion, Sequenz und Iteration - das genügt und der Rest Syntactic Sugar. Delphi kann sich nicht ewig und drei Tage am Schulpascal orientieren. In den 80ern war Assembler notwendig und zum Teil noch interessant. Zu Zeiten als OO aufkam haben die Sprachdetails und deren Aufbau kaum mehr einen interessiert. Heute ca. 25 Jahre nach der Verbreitung von OO interessiert kaum mehr einen woher die Klassen kommen und von welchem Typ sie sind.

Diese Entwicklung kann man seit Beginn der Programmierung in Assembler schön nachverfolgen. Bspw: Klammerung in Pascal im Falle der Selektion (IF). Früher: Ist regulärer Ausdruck - ist so. Heute: So a Schas, warum soviele Klammern.

Du hast heute eine stärkere Trennung zwischen jenen die ein Class Library bauen (als eigenes Unternehmen). In den 90ern gab es noch Bibliothekare in einer programmierenden IT Organisation, wobei diese Jobs eigentlich aus den U.S. Großprojekten (Regierung) abstammen (1995 ein Projekt mit bis zu 2 Mio. Klassen).

Ich kann mich no erinnern an eine Grenze bezüglich der Anzahl von Klassen die eine Klassenbibliothek namens ICLU hat überstiegen und dahinter hatte man schon die liebe Not mit der Verwendung. Ab dem Punkt verschwimmt die Würdigung einstiger Eleganz mit dem Empfinden von 'Bremsklotz'. Beim Delphi hat sich das Thema Inline-Deklaration schon bei den Interfaces und COM angekündigt. Ein handvoll Variablen in der Section vom Typ XYZVariant sind auch nichtssagend.

Sobald Sprachen und Umgebungen erlauben eine Mio. Klassen zu handeln kommt das nächste Framework mit 10 Mio :-D.

Ich kann mich noch an einen Anruf im Rahmen des Supports erinnern. Liegen die Daten beim Rudi?. Ja, gleich neben seinem COBOL Code. Na dann ist es eh recht. Weit von dem Zustand sind wir bspw. im Umfeld der Webentwicklung nicht mehr. Daten liegen beim Google, gehen wir auf ein Bier. Irgendwie werden wir sie schon bekommen.

Zitat:

Zitat von Codehunter (Beitrag 1416546)

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"... :evil:

Da wär mir das try-except-finally-Konstrukt aber 1000x lieber gewesen.

EDIT: Warum ein neuer Compilerdialog? Der alte war so richtig schön nostalgisch und glaub ich seit Delphi 2 unverändert (von VCL-Themes mal abgesehen)