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;
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.