Record helper für statische Arrays

[freimatz]

"Zumal der Mehraufwand hier wohl wirklich minimal gewesen wäre" - das sagen meine Kunden auch immer
Ich kann mir vorstellen dass es doch etwas mehr Aufwand ist. Ein record hat per see schon mehrere unterschiedliche Elemente, da noch etwas hinzufügen ist einfacher als bei etwas, das nur aus lauter gleichen Elementen besteht. Aber das ist nur eine Vermutung, ich kenne die Internas nicht.

"Naja, wozu mal Helper nunmal "braucht". Als Erweiterung für Typen, die man nicht ableiten will oder kann." - zu kann fallen mir alle Typen aus der RTL, VCL u.a. ein. Statische arrays sind mit da noch nicht untergekommen.
Selber haben wir öffentliche statische arrays nur bei Vektoren und Matrizen. Das gilt bei uns auch schon veraltet, man sollte den Record nehmen der das kapselt. So hat das ja auch himitsu vorgeschlagen.
In anderen Fällen würde ich eh immer eine Klasse drum rum bauen.

[Dennis07]

Zitat von freimatz:

Ein record hat per see schon mehrere unterschiedliche Elemente, da noch etwas hinzufügen ist einfacher als bei etwas, das nur aus lauter gleichen Elementen besteht. Aber das ist nur eine Vermutung, ich kenne die Internas nicht.

Naja, aber erstens haben Strings, Zahlen und dynamische Arrays auch keine Member, und zweitens sind das ja keine "echten" Member, sondern nur globale Routinen mit einem entsprechenden Parameter als "Self". RTTI und vererbung gibt es bei Helpern ja gar nicht. Insofern bezweifle ich durchaus, dass es tatsächlich noch mal deutlich mehr Arbeit gewesen wäre, das zu implementieren. Mir erscheint es eher wie eine willkürliche Einschränkung zu sein, als einen echten technischen Hintergrund zu haben.

Zitat von freimatz:

zu kann fallen mir alle Typen aus der RTL, VCL u.a. ein. Statische arrays sind mit da noch nicht untergekommen.
Selber haben wir öffentliche statische arrays nur bei Vektoren und Matrizen. Das gilt bei uns auch schon veraltet, man sollte den Record nehmen der das kapselt. So hat das ja auch himitsu vorgeschlagen.
In anderen Fällen würde ich eh immer eine Klasse drum rum bauen.

Joa, könnt ihr ja machen wie ihr wollt. Aber manchmal nimmt man halt Arrays, weil Records halt auch ihre Nachteile haben. Besonders wenn es darum geht, dass Record-Felder ja als Eigenschaften und Parameter ja Readonly sind.

Zitat von himitsu:

Wobei es so bei statischen Arrays und Records davon abhängt, was für Typen drin sind.
Strings und Interfaces und schon werden dieses Records/Arrays auch initialisiert und finalisiert (bzw. sie müssen es, sonst Preng und/oder Speicherlecks)

Joa eben, deshalb bringt es ja nichts...

[himitsu]

Vererbung gibt es bei Helpern.

Zum Glück, denn sonst wären Helper zu nichts zu gebrauchen, wenn man selber Typen erweitern will und dann mit den vordefinierten Helpern kollidiert.
Ich hoffe aber noch, dass der Entwickler irgendwann mal den gravierenden Bug behebt, wonach immer nur der letzte Helper nutzbar ist, denn Helper aus Fremdkomponenten können nicht voneinander erben, vor allem nicht firemübergreifend.

[Uwe Raabe]

Zitat von himitsu:

Vererbung gibt es bei Helpern.

Nur bei class helper for, nicht bei record helper for.

[himitsu]

Na das ist dann ja richtig doof.

[Dennis07]

Ich weiß im Augenblick nicht ganz, was ihr mit "Vererbung" hier meint. Denn Class Helper lassen sich ja nicht ableiten.

[Neutral General]

Es zählt immer nur 1 Helper. Wenn du 2 Helper für den gleichen Typen machst gilt immer nur der neuste (bzw. am "nächsten" deklarierte)

[Uwe Raabe]

Zitat von Dennis07:

Ich weiß im Augenblick nicht ganz, was ihr mit "Vererbung" hier meint. Denn Class Helper lassen sich ja nicht ableiten.

Doch!

Hier zwei Beispiele:

Delphi-Quellcode:

program Project624;

{$APPTYPE CONSOLE}

uses
  FMX.Types3D;

type
  TMyContexHelper = class helper (TContextHelper) for TContext3D
  public
    procedure Hurz;
  end;

procedure TMyContexHelper.Hurz;
begin
end;

var
  context: TContext3D;
begin
  context.FillCube(NullPoint3D, NullPoint3D, 0, 0); // deklariert in TContextHelper
  context.Hurz;
end.

Delphi-Quellcode:

program Project639;

{$APPTYPE CONSOLE}

uses
  System.Net.HttpClient;

type
  TMyHelper = class helper (THTTPClientHelper) for THTTPClient
  public
    procedure Hurz;
  end;

procedure TMyHelper.Hurz;
begin
end;

var
  Client: THTTPClient;
begin
  client.UseDefaultCredentials := True; // deklariert in THTTPClientHelper
  client.Hurz;
end.

[Jost Riedel]

Wenn man allerdings das statische Array in einen record einhüllt, dann braucht keinen record helper mehr:

type
ByteArray10 = record
x: array[0..10] of Byte;
procedure DoWhatever;
end;

procedure ByteArray10.DoWhatever;
begin
end;

Es ist schon spaßig: Für records braucht man keine "record helper", einen helper für einen enumerierten Typ, ein Set, usw. "record helper" zu nennen ist schon etwas irreführend.

[himitsu]

Jupp, siehe Antwort #3.

Zitat von himitsu:

Aber dann braucht man den Helper nicht unbedingt und kann es auch direkt in den Record reintun.

Wenn man einfach nur den "grundlegenden" Unterschied von Record und Klasse nimmt, dann wäre die Sache etwas klarer.
* CLASS für Klassen, also alles mit impliziten Pointern
* RECORD für alle Records und native Typen ohne Pointer, wo die Daten direkt in der Variable stecken (ja, auch der Pointer selbst ist ein nativer Typ)

Wobei hier der STRING und dynamische Arrays demnach ja eigentlich einen Class-Helper benötigen würden.
Dann vielleicht CLASS Helper eben für Klassen und Interfaces, welche mit einem Contructor erstellt werden müssen, und RECORD für alles Andere.

Gut, Helper ist Helper und man hätte eigentlich keine verwirrend unterschiedlichen Namen benötigt.