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