Einstieg in Zeiger auf Methoden / Funktionen

[generic]

Moin DP,

das nächste Video ist fertig. Heute zeige ich einen Einstieg in Zeiger auf Methode bzw. Funktionen.
Dabei beschränke ich mich erst einmal auf die Benutzung. In einen weiteren Video, zeige ich dann die eigene Implementierung.

Mit Zeiger auf Funktionen, könnt ihr ein Dinge einfach entkoppeln und ggf. im vorhandenes im Verhalten beeinflussen.
Zum Beginn zeige ich wie die VCL Ereignisse für die Oberfläche verwendet werden können und ggf. per Hand implementiert werden können. Später im Video ändern wir das Sortierungsverhalten einer Kundenliste und die Entkopplung der Kunden-Logik von der Oberfläche.

Der Quelltext vom Video ist hier:
ZeigerAufFunktionenVideo.7z

Das Video ist dieses:
https://youtu.be/7PL_H2aBUOI

[Gyrospeter]

Vielen Dank, bin heute drauf gestoßen. Werde es mir dann zuhause anschauen =)

[Rollo62]

Dankesehr für die Mühe, schaue ich mir später an.

Bist Du in Richtung funktionale Programmierung unterwegs ?
Wäre mal interessant zu wissen und zu vergleichen wie weit man mit Delphi kommen kann,
im Vergleich mit echten funktionalen Sprachen.

Ich nutze Pointer auf Funktionen jetzt schon ausgiebig, aber ich würde da gerne noch bis an die Grenze des Möglichen gehen.
Vor Allem: Wie bekommt man das Ganze auch noch lesbar und intuitiv verständlich eingepackt ...
Ich arbeite da meistens mit ziemlich strenger Nomenklatur, was mir die Sache vereinfachen soll,
aber schöner wären womöglich clevere Hilfsklassen um das besser zu kapseln.
Leider komme ich im Moment kaum dazu mir um theoretische Fragen viele Gedanken zu machen,
ich hoffe das es dazu dann mehr in deiner Serie gibt

Ist das so ungefähr auch die Richtung in die deine Videoserie gehen wird ?

[himitsu]

In Richtung NextGen (Android/iOS) ist sowas für Dialoge schon nötig.

Dialoge halten dort ja nicht mehr an, also mußt du für die Auswertung des gedrückten Knopfes eine Eventmethode schreiben.

Mit den anonymen Methoden (Generics) kannst bissl in Richtung von Lamda-Methoden gehen.

[Rollo62]

Hallo himitsu,

falls Du mich meinst, dankesehr für die Info.
All das nutze ich bereits ausgiebig, hoffe aber dass man da noch Einiges optimieren kann.

Anonyme Methoden sind nicht wirklich mit Lambdas, Funktoren, etc. aus anderen Sprachen vergleichbar, würde ich sagen.
Die Frage für mich ist: Was geht, was geht gar nicht, was geht aber sollte man besser lassen.

Z.B. Verschachtelte anonyme Methoden, wie weit kann man das Treiben ?
Kann man die womöglich besser lesbar machen durch Hilfsklassen, Generics, etc.

Ich bin da so ein bischen unschlüssig ob es da überhaupt gute Konzepte gibt,
um das in Delphi tiefer zu verschachteln als in Level 1.

[himitsu]

Verschachteln kann man die Anonymen bestimmt unendlich. (außer siehe unten)

Die geteilten Variablen (auf die man innerhalb der Methode zugreift) werden vom Compiler in ein Interface verschoben damit sie überall eindeutig gültig sind.
Kannst in etwa mit dem Self-Parameter in Klassenmethoden vergleichen.

Delphi-Quellcode:

procedure Xyz;
var
  x, y: Integer;
begin
  x := 0;
  y := 0;
  Call(procedure
    begin
      if x = 0 then
        ;
    end)
end;

wird zu

Delphi-Quellcode:

type 
  AnonymusVars0123456 = interface(record)
    x: Integer;
    P: AnonymusProc0123456;
  end;

procedure AnonymusProc0123456(Self: AnonymusVars0123456);
begin
  if Self.ax = 0 then
    ;
end)

procedure Xyz;
var
  y: Integer;
  a: AnonymusVars0123456;
begin
  a := Create...;
  a.P := AnonymusProc0123456;

  a.x := 0;
  y := 0;
  Call(AnonymusVars0123456);
end;

So lange der Compiler kein Limit (statische Liste oder zu wenig Speicher) hat, sollte es da keine Grenze geben. (außer dem Speicher)



Och, ich mach es mir da einfach: alles was man noch lesen kann, das ist erlaubt.
SpaghettiCode mag angeblich niemand, aber z.B. für kleine Synchronisierungsaufgaben, verwende ich die Anonymen gern mal ... finde es einfacher und übersichtlicher, als da die Prozedur ganz wo anders zu haben und immer im Zickzack gucken zu müssen.

Delphi-Quellcode:

// im Thread
...
mach was mit Ergebnis in S
...
TThread.Synchronize(nil, procedure
  begin
    ShowMessage(S);
  end);

Vom linearen Arbeiten wegzukommen, hin zum Prozedualen ist auch nicht immer so einfach.
Da ist man es bisher halt gewohnt, dass die MessageBox wartet und kann dann direkt danach den Code für die Auswertung machen.
Und nun soll das danach alles in eine/mehrere Prozeduren, die man dann dem Dialog mitgibt.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
  if ShowDialog('wirklich?') = mbOK then
    DeleteDirectory('C:\Windows\*')
  else
    ShowDialog('OK, dann net').
end;

Daraus sollen nun 2 bis 3 Methoden werden.

Ist halt wie alles als Methoden in der Form zu haben, anstatt es in eigene Klassen auszulagern.