Neue Sprachfeatures in Delphi?

[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)