Accessing a Record Structure Programatically

[Hansa]

Zitat:

Zitat von Pluto

Noch ein Hinweis:
Nicht jeder, der hier eine Frage stellt, ist ein Anfänger. Bemerkungen wie "also OOP lernen" sollte man mit Vorsicht verwenden!..

Der Titel lässt aber andere Schlüsse in Richtung "Anfänger" zu !! Du willst zudem einem Record Intelligenz beibringen. Das ist aber OOP, ob es Dir passt oder nicht.

[grenzgaenger]

Zitat:

Zitat von Pluto

War hier unpassend, zumal die Frage sich auf Records bezog. Ein Record ist ein Typ aber kein Objekt. Den hat schon Prof. Wirth 1972 definiert, als noch niemand an Objekte dachte.

ganz so ist es nicht. hier war schon der vertreter von objektorientierung schlechthin (Smalltalk lebendig. hatte damals aber die allgemeinen programmiersprachen noch nicht infiziert.

siehe hierzu auch:

• Geschichte
• Zeittafel

PS: records und opp sind zwei welten. denn die idee von opp war ja gerade intelligente daten zu kreieren welche wissen wie sie verarbeitet werden können. daher wäre die recorderweiterung seit D2006 als mini-opp anzusehen :-)

[toms]

Zitat:

Zitat von Pluto

Googlen brachte einen Eintrag von www.experts-exchange.com, der eine Lösung versprach.
Die sind recht teuer! Hab's doch mal mit einem Probeaccount versucht:

Ich habe noch einen Gratis Account von früher.
Du kannst den Direktlink angeben, dann kann ich schauen, ob dort etwas zutreffendes steht.

[alzaimar]

Da Records statisch sind, ist es überflüssig, die RTTY-Information im Code verfügbar zu machen.

Du kannst aber einen Parser implementieren, der deine Recordstruktur einliest und die entsprechende Information zur Laufzeit generiert. :mrgreen:

[sx2008]

Zum Thema OOP:
ein guter Programmierer muss merken, wenn ein Record für das gegebene Problem zu schwach ist
und aus dem Record eine Klasse machen.
Er wird dem Record auch nicht länger nachtrauern, sondern die Änderung wird durchgezogen
(je früher desto besser).
Und wenn es an vielen Stellen eine Umstellung gibt, zeigt das nur, wie bitter nötig dies war.

Zum Thema Array:
viele Programmierer greifen zum Array (meist zum dynamischen Array) obwohl eine TList-Klasse
wesentlich geeigneter für das Problem wäre.
Ein Array hat keine eigene Intelligenz, während TList, TObjectList, ... dem Programmierer viel Arbeit abnehmen!

Zum Thema Quicksort:
Beim Sortieren werden im Prinzip nur 2 Funktionen benötigt COMPARE und EXCHANGE.
Exchange, also das Vertauschen zweier Elemente, ist für TList völlig problemlos, ganz gleichgültig
welche Daten vertauscht werden. (beim Array geht das nicht)
Beim Compare, also das Vergleichen zweier Element wird Detailwissen über die Daten notwendig.
Hier kann eine Klasse gegenüber einem Record seinen Vorteil ausspielen, denn die Compare-Methode kann quasi automatisch bereitgestellt werden.

Zitat:

Zitat von Hansa

Wie wärs denn mit einem Listen-Objekt ? In TObjectList kann man die Record-Struktur reinpacken und das Ding kennt die Methode Sort. Es müsste also nur eine Vergleichsroutine gebastelt werden.

Genau das ist der richtige Weg!
Noch einfacher ist allerdings mein Vorschlag mit den MemoryDatasets. Da bekommst du suchen, sortieren, usw. auf dem Silbertablett geliefert.
Ein Memorydataset ist sozusagen eine TObjectList mit eingebauter RTTI und vielen zusätzlichen Funktionen.

[himitsu]

Zitat:

Zitat von sx2008

Exchange, also das Vertauschen zweier Elemente, ist für TList völlig problemlos, ganz gleichgültig welche Daten vertauscht werden. (beim Array geht das nicht)

Also das Vertauschen zweier (gleich aufgebauter) Records ist auch ohne wissen des Recordaufbaus extrem einfach möglich ... muß ja nur der Speicherinhalt getauscht werden.

Zum Vergleichen hast'e aber recht, denn ohne Wissen über den Aufbau weiß man ja nicht wie man was vergleichen muß.


Aber ob man nun das Wissen über den Aufbau in der Programlogic versteckt, oder in einem Objekt einbaut ... irgendwo muß dieses wissen dennoch hin, also ist doch für so einen einfachen Aufbau kaum ein Unterschied (Record<>Object), nur daß man beim Objekt und wenn es an mehreren Stellen im Programm verwendet wird, alles etwas besser sortiert hat (direkt im Objekt).
nja, dafür haben Object/TList,TTMemoryTable und Co. wiederrum einen etwas/wesendlich größeren Overhead, als der pure Record.

[Pluto]

Dank für alle Antworten!

an grenzgänger:

Du hast Recht: Ich muß mich korrigieren. Pascal war etwa zeitgleich zu Smalltalk.
Die Links waren sehr interessant. Da habe ich dann noch etwas tiefer gegraben:
Erste Gedanken und Entwicklungen zu OOP findet man in der Literatur bereits Anfang 1960 !

an toms:

Dank für Deinen Vorschlag - aber ich habe die unbrauchbaren Antworten bereits gelesen.

an alzaimar:

Das ist richtig, RTTI war ein Irrweg. Parsen ist möglich, die Exe wertet ja den Record aus,
also kennt sie auch die Struktur.
Das wäre hier aber overkill. Mein Programm läuft, auch wenn der Code etwas weniger
elegant ist, als ursprünglich gedacht.

an sx2008:

zu Quicksort:
Auch bei Arrays kann ich zwei Elemente vertauschen, meine Quicksort Routine für
Arrays läuft einwandfrei.
zu MemoryDataset:
Mir ist nicht klar, was Du mit "MemoryDataset" meinst. In der Delphi-Hlfe taucht dieser Begriff nicht auf.
Meinst Du etwa TClientDataset?
Das verwende ich in Datenbankprogrammen nahezu überall. Es ist blitzschnell, hat viele Vorzüge, wie
Filtern und Clonen, auch kann man kleinere Tabellen einfach als XML abspeichern und laden.

Allerdings werde ich bei begrenzten kleineren Strukturen auch weiterhin Arrays benutzen.
So z.B. für Matritzenberechnungen. Da bleibt der Code einfach und übersichtlich.
OOP kann manchmal auch overkill sein. Man sollte der Aufgabe angepasst pragmatisch, nicht dogmatisch programmieren.

Grüße,
Pluto