verschiedene class helper für eine Klasse

[Redeemer]

Dann gilt die Reihenfolge der uses wie überall sonst auch, z.B. bei Klassen (ja, ich meine dich, TBitmap!) oder "globalen Methoden". Da allerdings der Class Helper keinen nach außen sichtbaren Namen hat, kann man dann leider nicht die Auswahl überschreiben, indem man die Unit angibt.

[himitsu]

Zitat von Redeemer:

Dann gilt die Reihenfolge der uses wie überall sonst auch, z.B. bei Klassen (ja, ich meine dich, TBitmap!) oder "globalen Methoden". Da allerdings der Class Helper keinen nach außen sichtbaren Namen hat, kann man dann leider nicht die Auswahl überschreiben, indem man die Unit angibt.

Wo soll es da ein Problem geben?
Genauso, wie Overload, bzw. Ohne.

Der Helper, welcher zuletzt im Scope liegt, dessen Methode/Property hat Vorrang. (je nach Signatur)

[Redeemer]

Das Problem ist, dass du die Auswahl des Compilers nicht überschreiben kannst, falls jeweils ein Class Helper für dieselbe Klasse in zwei Units dieselbe Methodensignatur hat.

Delphi-Quellcode:

unit Unit1;

type
TWuppdiHelper1 = class helper for TWuppdi
  procedure DoWuppdi();
end

Delphi-Quellcode:

unit Unit2;

type
TWuppdiHelper2 = class helper for TWuppdi
  procedure DoWuppdi();
end

In einer Unit, die beide Units einbindet, kann man dann doch nur eines der DoWuppdi() aufrufen.

[DeddyH]

Dann wird eben der genommen, der zuletzt eingebunden wurde. Das geht mit regulären Prozeduren ja auch.

[Uwe Raabe]

Worauf Janni hinaus will ist wohl, dass man bei Helpern nicht einfach den Unit-Namen voranstellen kann, um den Default zu überschreiben.

[DeddyH]

Ja gut, dann ist das eben so. Aber der Ist-Zustand ist ja auch nicht das Gelbe vom Ei.

[Uwe Raabe]

Zitat von DeddyH:

Ja gut, dann ist das eben so. Aber der Ist-Zustand ist ja auch nicht das Gelbe vom Ei.

In der Tat! Man vermeidet damit zwar ein Teilproblem einer Multi-Helper Implementierung, verhindert aber die übrigen Möglichkeiten, die mit so einem Feature daherkommen.

Das Problem trifft ja auch nur bei Helpern zu, die man nicht selbst unter Kontrolle hat, sonst könnte man ja die Namen anpassen.
Aber da dann ja beliebig viele Helper erlaubt sind, gäbe es doch einen Workaround:

Delphi-Quellcode:

unit Unit1Wrapper;

interface

type
  TWuppdiHelper1Wrapper = class helper for TWuppdi
    procedure DoWuppdi1();
  end;

implementation

uses
  Unit1;

procedure TWuppdiHelper1Wrapper.DoWuppdi1;
begin
  DoWuppdi;
end;

Delphi-Quellcode:

unit Unit2Wrapper;

interface

type
  TWuppdiHelper2Wrapper = class helper for TWuppdi
    procedure DoWuppdi2();
  end;

implementation

uses
  Unit2;

procedure TWuppdiHelper2Wrapper.DoWuppdi2;
begin
  DoWuppdi;
end;

Die Wrapper-Units müssen dann ja auch nur die Namenskollisionen auflösen, der Rest kann ja so verwendet werden.

Übrigens kann ma mehrere Helper für eine Klasse schon jetzt realisieren, wenn man die Helper ableitet (muss man halt auch den Source haben und funktioniert leider nicht bei record helper):

Delphi-Quellcode:

type
  TWuppdiHelper1 = class helper for TWuppdi
    procedure DoWuppdi1;
  end;

type
  TWuppdiHelper2 = class helper(TWuppdiHelper1) for TWuppdi
    procedure DoWuppdi2;
  end;

...

  var wuppdi := TWuppdi.Create;
  try
    wuppdi.DoWuppdi1; // Code Completion sieht das zwar nicht, aber der Compiler schon.
    wuppdi.DoWuppdi2;
  finally
    wuppdi.Free;
  end;

Zitat von DeddyH:

Manchmal bekommt man ja auch den Eindruck, dass mit viel Getöse neue supertolle Features für die nächste Delphi-Version angekündigt werden, die sich dann, wenn man sie etwas intensiver als in den mitgelieferten Demos benutzen möchte, als Papiertiger erweisen.

Mein Nutzungsgrad von Helpern ist allerdings so hoch, dass man da mitnichten von Papiertigern sprechen kann.

[Redeemer]

Zitat von Uwe Raabe:

Worauf Janni hinaus will ist wohl, dass man bei Helpern nicht einfach den Unit-Namen voranstellen kann, um den Default zu überschreiben.

Richtig. Und ich vermute, dass das der Grund ist, warum sie zwei Class Helper im Scope nicht zulassen.
Allerdings dürfte es keinen plausiblen Grund geben, für dieselbe Klasse zwei Helper-Methoden mit derselben Methodensignatur zu schreiben, die unterschiedliche Dinge tun. Also dürfte das von mir beschriebene Problem gegenüber der Einschränkung auf nur 1 Class Helper im Scope das geringe Übel sein.

[DeddyH]

Manchmal bekommt man ja auch den Eindruck, dass mit viel Getöse neue supertolle Features für die nächste Delphi-Version angekündigt werden, die sich dann, wenn man sie etwas intensiver als in den mitgelieferten Demos benutzen möchte, als Papiertiger erweisen.