CX_FORMULA Variable

Klasse CX_FORMULA - Variable

Variablen einer Formel können beliebige Zugriffsausdrücke sein. Vor Berechnung einer Formel werden die Variablen gebunden, die Zugriffsausdrücke ausgewertet. Beim Binden von Variablen (und von externen Funktionen) werden die Zugriffsausdrücke für die im PlugSpace registrierten Objekt solange nacheinander ausgewertet, bis ein Wert für den jeweiligen Zugriffsausdruck gefunden wurde (siehe Befehl Plug). Dieser Wert wird anstelle des Zugriffsausdrucks (Variable oder Funktion) in die Formel übernommen. Wurden alle Zugriffsausdrücke ersetzt, wird die Formel berechnet.

Die (gewollte) Reihenfolge der Objekte im PlugSpace ist wichtig, da eine Variable mit verschiedenen Objekten gebunden sein könnte.

Dynamische Datenfelder (Slots) kommen besonders oft als Variablen in Formeln vor und werden deshalb intern besonders behandelt, d.h. die Repräsentation und Bindung an Objekte im PlugSpace sind effektiver als im allgemeinen Fall.

Bezüglich der Bindung gibt es zwei Modi: locker bzw. eng.  Der Normalfall für Objekte in Formeln ist die lockere Bindung, d.h. einige Klassen definieren eine implizite Erweiterung des PlugSpace, indem sie bestimmte Objektreferenzen zusätzlich nach dem gesuchten Datenfeld durchsuchen. Um den Normalfall der erweiterten Suche zu umgehen (siehe Unterschied der Bindungssemantik) kann durch die Nutzung von get/has eine enge Bindung vorgegeben werden.

Welcher Ausdruck welche Bindungssemantik vorgibt, zeigt die nachstehende Tabelle:

Modus	Variable x als Operand	Test auf Existenz der Variablen x
locker	x	available(x)
eng	get(x)	has(x)

 

Unterschied der Bindungssemantik

Die folgende Tabelle listet auf, welche Klasse bei welcher Bindung welche Datenfelder in welcher Reihenfolge auswertet.
Der Befehl Plug hat grundsätzlich die gleiche Semantik, wie die lockere Formelbindung für Zugriffsausdrücke. Die Bindungssemantik der Befehle Copy / Get ist grundsätzlich gleichbedeutend mit der engen Formelbindung für Zugriffsausdrücke.

self steht in der nachfolgenden Tabelle für die direkten Datenfelder des Objekts selbst. (Also nur die eigenen Slots und direkten Datenmember).
Die anderen fett gedruckten Bezeichnungen stehen für die Datenfelder der entsprechenden Objekte.
235541 

Klassen	lockere Bindung: X / available(X) / Plug(...)		enge Bindung: get(X) / has(X) / Copy(...) / Get(...)
CX_SLOT_ATTRIBUTE Voreingestelltes Attribut (attributeEnum0 = 0)	self
CX_SLOT_ATTRIBUTE Sachmerkmal (attributeEnum0 = 1)	self1		self
CX_ATTRIBUTE_SET	self attributes2,3 (CX_ATTRIBUTE)		self attributes2 (CX_ATTRIBUTE)
CX_ITEM CX_ITEM_PATTERN CX_ALLOCATION	self attributeSet2,3 (CX_ATTRIBUTE_SET)		self attributeSet2 (CX_ATTRIBUTE_SET)
CX_SINGLE_ALLOCATION	self attributeSet2,3 (CX_ATTRIBUTE_SET) object (CX_BUSINESS_OBJECT)
CX_ALLOCATION_TXN	self attributeSet2,3 (CX_ATTRIBUTE_SET) object (CX_EXPANDABLE) allocation (CX_ALLOCATION) transaction (CX_TRANSACTION) resolvePath (CX_EXPANDABLE)		self
CX_ITEM_CAST	self attributeSet2,3 (CX_ATTRIBUTE_SET) item (CX_ITEM)
CX_TRANSACTION	self transaction (CX_TRANSACTION)
CX_STRUCTURE	self masterStructure (CX_STRUCTURE)
CX_PARTNER_CAST	self partner (CX_PARTNER)

self¹ = Nur für Attribute, die als Sachmerkmale gekennzeichnet sind: Falls der gesuchte Slot vom Attribut selbst repräsentiert wird (die ID (CX_VESSEL::GetSlotNumber) des Slots stimmt mit dem Feld attribute überein), dann wird der Slot-Wert nicht gefunden, auch wenn der Slot im CX_SLOT_ATTRIBUTE existiert. Alle anderen Slots werden im CX_SLOT_ATTRIBUTE-Frame gefunden.

attributes² / attributeSet² = Nur der Frame des CX_ATTRIBUTE_SETs und die Attribute (attributes Collection) werden für den gesuchten Slot berücksichtigt (gesuchter Slot = attribute). In den Attributen wird nur dieser Slot der berücksichtigt. Es wird NICHT der gesamte Frame der enthaltenen CX_ATTRIBUTE-Objekte durchsucht.

attributes³ / attributeSet³ = Attribute, die Sachmerkmale sind, werden bei der Suche nicht berücksichtigt.

 

 

 

Alte Bindungssemantik (vor Dll-Version 235541)

Die folgende Tabelle listet auf, welche Klasse bei welcher Bindung welche Datenfelder in welcher Reihenfolge auswertet.
Das ClassiX-System unterscheidet nicht nur zwischen enger und lockerer Bindung, sondern wie in der obgien Tabelle bereits angedeutet auch zwischen Slots und ganzen Zugriffsausdrücken. So hat get(number) manchmal eine andere Semantik als get(this.number).
Der Befehl Plug hat grundsätzlich die gleiche Semantik, wie die die lockere Formelbindung für Zugriffsausdrücke.
Die Spalte "Copy / Get / get(ausdruck)" beschreibt zusätzlich die Semanik wenn die Befehle Copy oder Get auf dem Objekt ausgeführt werden - Die Bindungssemantik dieser beiden Befehle ist grundsätzlich gleichbedeutend mit der engen Formelbindung für Zugriffsausdrücke.

this steht in der nachfolgenden Tabelle für die direkten Datenfelder des Objekts selbst. (Also nur die eigenen Slots und direkten Datenmember)

Klassen	lockere Bindung (slot)	lockere Bindung (ausdruck) / Plug(...)	Copy(...) / Get(...) / get(ausdruck)	get(slot)
CX_SLOT_ATTRIBUTE Voreingestelltes Attribut	this			this
CX_SLOT_ATTRIBUTE Sachmerkmal	this1		this
CX_ATTRIBUTE_SET	this attributes2	this attributes (CX_ATTRIBUTE)
CX_ITEM CX_ALLOCATION	this attributeSet2 (CX_ATTRIBUTE_SET)	this attributeSet (CX_ATTRIBUTE_SET)
CX_SINGLE_ALLOCATION	this attributeSet2 (CX_ATTRIBUTE_SET) object (CX_BUSINESS_OBJECT)	this attributeSet (CX_ATTRIBUTE_SET) object (CX_BUSINESS_OBJECT)	this attributeSet (CX_ATTRIBUTE_SET)
CX_ALLOCATION_TXN	this attributeSet2 (CX_ATTRIBUTE_SET) object (CX_EXPANDABLE) allocation (CX_ALLOCATION) transaction (CX_TRANSACTION) resolvePath (CX_EXPANDABLE)	this attributeSet (CX_ATTRIBUTE_SET) object (CX_EXPANDABLE) allocation (CX_ALLOCATION) transaction (CX_TRANSACTION) resolvePath (CX_EXPANDABLE)	this
CX_ITEM_CAST	this attributeSet2 (CX_ATTRIBUTE_SET) item (CX_ITEM)	this attributeSet (CX_ATTRIBUTE_SET) item (CX_ITEM)
CX_TRANSACTION	this transaction (CX_TRANSACTION)
CX_STRUCTURE	this masterStructure (CX_STRUCTURE)
CX_PARTNER_CAST	this partner (CX_PARTNER)
CX_ITEM_PATTERN	this attributeSet3 (CX_ATTRIBUTE_SET)	this5 attributeSet4 (CX_ATTRIBUTE_SET)	this attributeSet (CX_ATTRIBUTE_SET)

this¹ = Falls der gesuchte slot = attribute ist oder der Zugriffspfad mit dem in attribute gesetzten Slot beginnt, dann wird der Slot-Wert nicht gefunden, auch wenn der Slot im CX_SLOT_ATTRIBUTE existiert. Anderenfalls wird der Wert gefunden, falls der entsprechende Slot im CX_SLOT_ATTRIBUTE-Objekt gesetzt ist.

attributes² / attributeSet² = Attribute vom Typ CX_SLOT_ATTRIBUTE, die Sachmerkmale für den gesuchten Slot sind, werden bei der Suche nicht berücksichtigt.

attributeSet³ = Auf dem attributeSet wird Attribute() aufgerufen und der Zugriffspfad (Slotname) gegen das gefundene Attribut ausgewertet. Im Unterschied zu attributeSet² werden Sachmerkmale nicht einfach nur übersprungen, die Suche wird stattdessem beim ersten passenden Attribut abgebrochen. (siehe Beschreibung der Semantik von Attribute())

attributeSet⁴ = Falls der Zugriffsausdruck mit einem Slot beginnt, dann wird für diesen Slot auf dem attributeSet Attribute() aufgerufen. Falls ein passendes Attribut gefunden wurde, wird das Ergebnis jedoch verworfen und der Zugriffspfad mit der gleichen Semantik, wie CX_ITEM (Basisklasse) ausgewertet. Falls Attribute() kein passendes Attribut findet, liefert die Auswertung kein Ergebnis. Diese Semantik hat zur Folge, ein attributeSet mit enthaltener Sachmerkmalliste keinen Wert liefert, solange nicht auch ein Attributset mit voreingestellten Attributen enthalten ist. In dem Fall wird jeodch nicht das voreingestellte Attribut, sondern das Sachmerkmal zurückgegeben (bzw. immer das, welches zuerst gefunden wird().

this⁵ = Die Slots des CX_ITEM_PATTERN-Objekts werden nur dann durchsucht, falls der gepluggte Ausdruck NICHT mit einem Specifier/Slot beginnt. Beginnt der gepluggte Ausdruck nicht mit einem Slot, dann wird der Ausdruck mit der gleichen Semantik wie CX_ITEM (Basisklasse) ausgewertet. Beispiel: Plug(number) wird nur als Attribut gesucht, Plug(this.number) wird auch in den Slots gesucht.