"reference to procedure" vs. "procedure"

[Der schöne Günther]

Der Typ System.SysUtils.TProc ist definiert als reference to procedure .

Als Komfortfunktion kann ich somit nicht nur anonyme Methoden reinstecken, sondern auch "klassische" Prozeduren sowie eine "procedure of object". Beispiel:

Delphi-Quellcode:

type
   TMyObject = class
      class procedure p();
   end;

procedure p();
var
   myObject: TMyObject;
   p1, p2, p3: TProc;
begin
   p1 := p;
   p2 :=
      procedure()
      begin
         WriteLn('Hello world')
      end;

   p3 := TMyObject.p;
end;

Ganz dumme Frage: Kann ich das abstellen? Die Zuweisungen an p1 und p3 klappen, soweit ich das verstanden habe, nur weil der Compiler im Endeffekt

Delphi-Quellcode:

   p1 :=
      procedure()
      begin
         p();
      end;

und

Delphi-Quellcode:

   p3 :=
      procedure()
      begin
         TMyObject.p();
      end;

draus macht. Kann ich dieses ungewollte "Auto-Boxing" abstellen sodass nur p2 eine gültige Zuweisung ist?

[himitsu]

Nein.

PS: Der Compiler macht da ein generiesches Interface drum

Delphi-Quellcode:

TProcObject = class(TGeheimesInterface)
  FGesharteVariablen: IVariablen;
  FProc: procedure();
  FEvent: procedure() of object;
  ...
  procedure Call;
end;

TProcObject.procedure Call;
begin
  if Assigned(FProc) then
    FProc(FGesharteVariablen);
  if Assigned(FEvent) then
    FEvent(FGesharteVariablen);
  ...
end;

[freimatz]

Was hindert Dich Günther ein eigenes TProc zu definieren?

[Der schöne Günther]

Wenn du mir zeigst wie man das macht, gerne

[Uwe Raabe]

Zitat von freimatz:

Was hindert Dich Günther ein eigenes TProc zu definieren?

Das würde nichts bringen. Im einen Fall TProc = procedure würde nur die Zuweisung 1 klappen, bei TProc = procedure of object klappt nur Zuweisung 3. Wenn Zuweisung 2 klappen soll, dann funktionieren immer auch 1 und 3.

Es gibt übrigens noch einen vierten Fall:

Delphi-Quellcode:

type
   TMyObject = class
      procedure p();
   end;

...
   p4 := myObject.p;

[Der schöne Günther]

Ok, darauf hatte ich mich seelisch auch schon eingestellt.

Nette Compiler-Magic-Komfortfunktion, aber wäre halt schon wenn man auch mal sagen könnte "Nein danke".

[Uwe Raabe]

Zitat von Der schöne Günther:

Nette Compiler-Magic-Komfortfunktion, aber wäre halt schon wenn man auch mal sagen könnte "Nein danke".

Warum genau willst du das denn so?

[Der schöne Günther]

Angenommen ich habe Liste an TProcs. Wenn ich eine TProc in einer Variable speichere kann ich sie später mit dieser Referenz wieder in der Liste wiederfinden und herausnehmen.

Wenn ich "verboten" hätte dass man für TProc auch eine Instanz/Klassenmethode oder klassische Prozedur reinstecken kann wäre den Aufrufer klar geworden dass er sich das selbst in eine TProc-Variable stecken muss um sie später wieder in der Liste wiederzufinden.

Negativ-Beispiel:

Delphi-Quellcode:

procedure x();
begin
   WriteLn('x');
end;

procedure p();
var
   list: TList<TProc>;
begin
   list := TList<TProc>.Create();
   list.Add(x);
   Assert( list.Contains(x) ); // schlägt natürlich fehl
end;

Klar kommt man mit einer "Zwischen-Referenz" drum herum:

Delphi-Quellcode:

procedure p();
var
   list: TList<TProc>;
   proc: TProc;
begin
   list := TList<TProc>.Create();

   proc := x;
   list.Add(proc);

   Assert( list.Contains(proc) );
end;

aber mir wäre lieber gewesen wenn der erste Codeblock erst gar nicht compiliert hätte.

[himitsu]

In dem Referenz-Interface kann man zwar was auslesen, aber leider ist nicht sicher bestimmbar was es ist, da keine RTTI vorhanden und die Felder ala FProc/FEvent nicht existieren, wenn nicht verwendet ... das danach rutscht nach und man weiß nicht was in dem Speicher liegt.

Und ja, in soeinem Fall mußt du erst die Referenz erzeigen, speichern und kannst diese dann für den vergleich nutzen.
Ansonsten wird für beides Zuweisen und Vergleich jeweils eine eigene Instanz des Referenzinterfaces erstellt und die sind natürlich nicht gleich.

[freimatz]

Gibt es eigentlich bei dieser Sache einen Unterschied zwischen einer klassischen Prozedur und einer anonymen Methode? Bei einer Klassenmethode ist es mir klar, da wird ja intern noch Self als Parameter mit übergeben. Aber sind die anderen Fälle nicht gleich - zumindest vom aufruf. Ein Stück Code liegt im Speicher und wird aufgerufen. Dass die anonyme Methode keinen Namen (oder nur einen internen generierten) Namen hat kann doch hier keinen Unterschied machen. Oder?