Delphi XE3?

[mkinzler]

Nein funktioniert leider nicht.

Delphi-Quellcode:

type
    MyStringHelper = record helper ( System.SysUtils.TStringHelper) for string
        function Test;
    end;

Zitat:

[dcc32 Fehler] Project1.dpr(7): E2029 ',' oder ':' erwartet, aber '(' gefunden
[dcc32 Fehler] Project1.dpr(7): E2029 ',' oder ')' erwartet, aber '.' gefunden
[dcc32 Fehler] Project1.dpr(7): E2029 ';' erwartet, aber 'FOR' gefunden
[dcc32 Fehler] Project1.dpr(8): E2023 Funktion benötigt Ergebnistyp
[dcc32 Fehler] Project1.dpr(59): E2003 Undeklarierter Bezeichner: 'Test'

[Daniel]

Record-Helper lassen sich im Gegensatz zu Class-Helpern nicht ableiten.

Ich würde auch davon abraten, eine zu große und komplexe Hierarchie in den Helpern - die ja parallel zu den Business-Objekten stehen - etablieren zu wollen. Die Helper selbst sind ja nur Hilfswerkzeuge, die zwar punktuell ungemein praktisch sein können, aber kein Bestandteil des grundsätzlichen Anwendungsdesigns sein sollten.

[TiGü]

Zitat:

Zitat von mkinzler (Beitrag 1181787)

Nein funktioniert leider nicht.

Delphi-Quellcode:

type
    MyStringHelper = record helper ( System.SysUtils.TStringHelper) for string
        function Test;
    end;

Zitat:

[dcc32 Fehler] Project1.dpr(7): E2029 ',' oder ':' erwartet, aber '(' gefunden
[dcc32 Fehler] Project1.dpr(7): E2029 ',' oder ')' erwartet, aber '.' gefunden
[dcc32 Fehler] Project1.dpr(7): E2029 ';' erwartet, aber 'FOR' gefunden
[dcc32 Fehler] Project1.dpr(8): E2023 Funktion benötigt Ergebnistyp
[dcc32 Fehler] Project1.dpr(59): E2003 Undeklarierter Bezeichner: 'Test'

Und wenn du anstatt MyStringHelper es TStringHelper nennst?

Die Abhängigkeit anhand der Uses-Reihenfolge habe ich für Interceptor-Geschichten immer als recht angenehm empfunden.
Warum sollten für Helper andere Regeln gelten als für z.B. für Klassen?

Wie ist das, wenn man sich eigene Typen definiert und davon abhängig eigene Helper?

Delphi-Quellcode:

type
  MyString = System.String

  MyStringHelper = record helper for MyString
    function Test;
  end;

[BUG]

Ist wohl ein ähnliches Problem wie mit der Mehrfachvererbung (welche Methode bei gleichem Namen).
Das mit einer so künstlichen Einschränkung zu umgehen ist aber irgendwie typisch :|

Ableiten ist ja auch keine Lösung, wenn man Helper von verschiedenen Anbietern (und damit Units), benutzen möchte.

[TiGü]

Zitat:

Zitat von BUG (Beitrag 1181790)

Ableiten ist ja auch keine Lösung, wenn man Helper von verschiedenen Anbietern (und damit Units), benutzen möchte.

Wie oft kommt sowas vor?

[mkinzler]

Zitat:

Wie ist das, wenn man sich eigene Typen definiert und davon abhängig eigene Helper?

Dann wird nur die Funktion Test gekannt.

Zitat:

Warum sollten für Helper andere Regeln gelten als für z.B. für Klassen?

Weil es etwas anderes ist. Helper erweitern zur Laufzeit; keine echte Vererbung.

Zitat:

Ist wohl ein ähnliches Problem wie mit der Mehrfachvererbung (welche Methode bei gleichem Namen).

Es gibt gute Gründe, die gegen Mehrfachvererbung sprechen, dieser ist einer davon. Deshalb unterstützen Delphi, Java, C# usw. diese auch nicht.

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1181791)

Zitat:

Zitat von BUG (Beitrag 1181790)

Ableiten ist ja auch keine Lösung, wenn man Helper von verschiedenen Anbietern (und damit Units), benutzen möchte.

Wie oft kommt sowas vor?

Kommt schon vor - auch bei eigenen Helpern. Wenn ich bei einem Helper für eine Klasse immer die Vererbungshierarchie der Helper berücksichtigen muss, erhöht das nicht gerade die Modularisierung.

Was aber geht, sind mehrere class helper für unterschiedliche Basisklassen:

Delphi-Quellcode:

type
  TObjectHelper = class helper for TObject
  public
    procedure Foo;
  end;

  TComponentHelper = class helper for TComponent
  public
    procedure Bar;
  end;


procedure TObjectHelper.Foo;
begin
end;

procedure TComponentHelper.Bar;
begin
end;

procedure TForm158.FormCreate(Sender: TObject);
begin
  Foo;
  Bar;
end;

[himitsu]

Oh, hatte gedacht/gehofft, daß man mehrere Helper erstellen kann. :cry: (hab's bisher aber zufällig noch nie benutzt)

Gut, ein Problem ist die Vererbungsgeschichte, also vorrangig das Problem "Was passiert, wenn in 2 Helpern die selbe Methode (Methoden-Name) vorkommt".
Wenn man die Helper voneinander ableitet, wäre das Problem behoben.
(Nja, man hätte es doch stattdessen so implementieren können, daß erst beim Aufruf einer Helpermethode diese Abhängigkeiten geprüft worden wären und hätte dann dort eine Fehlermeldung geworfen)

[Insider2004]

Ich würde Helper überhaupt nicht nehmen. Dafür gibt es Klassen und Vererbung. Helper sollten die absolute Ausnahme bleiben. Schon wie der Name sagt, es sind Helfer. Also für Integer oder Floats z.b.. Ausserdem sind sie eigentlich nur für geschlossene Objekte gedacht, wo man den Quellcode nicht hat/kennt.

[himitsu]

Wieso nicht?

Verteilte Objekte

Man könnte zu Einer Klasse/Type mehrere Methoden-Listen erstellen, vorallem wenn man nicht immer alles braucht.

Gut, man kann weitere Klassen, über Property verschachtelt anbieden, aber da hat der Compiler es schwer (es ist unmöglich) daß der Compilier dieses wegoptimiert,
denn über das vorhandene Property, aber vorallem über das interne Feld (wo z.B. diese Objektinstanz gespeichert werden muß), ist diese Klasse immer bekannt und wird auch immer einkompiliert.

Die Andere Lösung ist eine komplett unabhängig Klasse, welche, wenn man sie nicht verwendet, natürlich nicht einkompiliert wird.
Da der Helper ebenfalls "unabhängig" ist, da die eigentliche Klasse/Typ Diesen nicht kennt, kann hier der Compiler es ebenfalls wegoptimieren.


Genauso wie alles immer vorhanden ist, welches irgendwo in den Initialization-Abschnitten initialisiert wird.
Nutzt man stattdessen den Class-Constructor, dann kann der Compilier diese Klasse weglassen, da die Initialization nicht statisch eingebunden wurde.
PS: Das ist auch einer der Gründe, warum bei der VCL alles so groß wird, im Vergleich zum NonVCL.