Ist natürlich auch eine Möglichkeit. Vermutlich sogar die bessere. Isotopen würde dann quasi sogar nebenbei das eigentlich als Element gedachte mitimplementieren (Element wäre ja nur ein spezielles set von Isotopen; Eventuell könnte man Isotopen dann sogar mit einem Switch austatten, das das wie ein Element reagieren lässt (eventuell dann auch nur bei neu erstellen setzbar - ja ich mache zum Teil "Build" prozeduren zum Initialisieren die dann nur einen Objektausgang haben; finde das irgendwie teils deutlich sinnvoller und natürlich mächtiger als einfach nur das Objekt ins BD zu setzen) - daher nur gültige Isotope sind hinzufügbar etc.).
Hmm... ja klingt insgesamt sehr sinnvoll.
Das heist aber auch, wenn man bestimmte Daten gemeinsam nutzen möchte in Labview muss man die zwingend "ausgliedern" (daher in nem eigenen Objekt Kapseln, dass man dann in seinem eigentlichen Objekt als attribut einfügt) ?
Trivialbeispiel mit kleinstem Datenaufkommen:
Ordnungszahl und Isotopenname seien die einzigen gemeinsamen Eigenschaften (daher bei verschiedenen Isotopen öfter gleich vorkommen). Die werden als Objekt
Bezeichner gespeichert. Dazu kommt ein Objekt
Bezeichnerliste, dass aus nem Array von Referenzen auf
Bezeichner besteht. Lege ich ein neues Isotop an, gibt das Name und OZ an Bezeichnerliste weiter. Die prüft ob der Bezeichner schon vorhanden ist oder neu angelegt werden muss und gibt anschließend eine Referenz aus mit der ich dann anschließend in Isotop weiterarbeiten kann.
So müsste ich doch dann minimale Speicherauslastung gewährleisten können - richtig?
*in dem Beispiel mit paar Kb und ner begrenzten Anzahl von maximal ein paar tausend Isotopen wenn man alle möglichen nimmt sicher nicht wichtig; aber es geht ja ums Prinzip*
Nachteile die ich auf Anhieb sehe:
1. Aus der Referenz kann ich mit nem Eigenschaftsknoten das Objekt rausholen - dabei dürften Racing Conditions auftreten können (grundsätzlich).
2. Nutzen mehrere andere Objekte den Speicherplatz gemeinsam muss klar sein, wie bzw. wann bzw. ob freigegeben werden darf.
zu 1.: Kann man vermeiden durch implementieren einer Sperrarchitektur in
Isotopenliste und Ansprache des Objekts
Bezeichner nicht über Eigenschaftsknoten sondern über die eine Instanz von
Bezeichnerliste die gemeinsam genutzt wird. Je nach Komplexität hieße das mehr oder weniger eine Art Semaphor setzen oder eben nicht
Im konkreten Fall wäre das nicht notwendig, da nur beim neu Anlegen geschrieben wird. Ansonsten wird nur gelesen.
zu 2.: Hier müsste man letztlich auch nur in
Bezeichnerliste "Buch führen" wie viele Bezeichner angefordert wurden. Die müssen wenn nichtmehr gebraucht dann explizit zurückgegeben werden (also zumindest nicht mehr Probleme als man auch so schon mit anzufordernden Referenzen auf Dateien etc. hat).
Im konkreten Fall vermutlich auch nicht wichtig, da die Bezeichner sowieso erst am Programmende zurückgegeben würden. Entsprechend würden die dann sowieso beim Programmende frei. Ist trotzdem durchaus nicht ganz ohne.
Aus 1 und 2 folgt jedenfalls, dass sich das vermutlich erst für entweder sehr viele Referenzen auf identische Objekte lohnt oder aber wenn auf große Datenmengen (Bilder) Referenziert werden soll.
Klingt das soweit sinnvoll?
Gruß Kiesch
