| Properties | |
| BESCHREIBUNG: | |
| Im Gegensatz zu Variablen innerhalb eines Objektes, kann man Properties | |
| von aussen veraendern, ohne eine besondere Funktion geschrieben zu haben. | |
| 1. Das zugrundeliegende Prinzip | |
| =============================== | |
| Das grundlegende Konzept der MUDlib ist, dass wichtige, objektbezogene | |
| Informationen in den sogenannnten Properties gespeichert werden (engl. | |
| property -- Eigenschaft, Eigentum). | |
| Diese Informationen koennen einfache Werte, wie z.B. Zahlen, Zeichen oder | |
| Objekte, aber auch kompliziertere Strukturen sein. | |
| Jedes Objekt kann beliebig viele solcher Properties besitzen und deren | |
| Namensgebung ist nicht nur auf die von der MUDlib bereitgestellten | |
| Standardproperties begrenzt. Das heisst, das fuer eigene Anwendungen die | |
| Menge der Properties fuer ein Objekt beliebig erweitert werden kann. | |
| Damit sind auch schon die beiden Hauptmerkmale einer Property ange- | |
| sprochen: | |
| a) ein Name oder Kennung und | |
| b) ein Wert, der durch den Namen repraesentiert wird. | |
| Das reine Verwalten einer Property mit Namen und Wert ist aber nicht sehr | |
| sinnvoll und so gehoeren zu jeder Property noch zwei weitere wichtige | |
| Dinge. Zu jeder Property wurden jeweils zwei Operationen eingefuehrt, | |
| welche den uebergebenen Wert vor der Speicherung oder Abfrage bearbeiten. | |
| Zusammenfassend laesst sich das Konzept der Property in folgendem Schema | |
| darstellen: | |
| +-------------------------------------------+ | |
| | Property | | |
| +-------------------------------------------+ | |
| | privater Datenbereich (Property Werte) | | |
| +-------------------------------------------+ | |
| | Direktzugriff auf den Datenbereich | | |
| +-------------------------------------+ | | |
| | ^ Methoden v | ^ v | | |
| | Setzen | Abfragen | | | |
| +-------------------------------------+-----+ | |
| ^ | | |
| | V | |
| SetProp() QueryProp() | |
| Aus dem Schema laesst sich Folgendes erkennen: | |
| - beim Setzen und Abfragen wird der Wert einer Methode uebergeben, die | |
| den Wert zurueckgibt oder ggf. die Aenderungen vornimmt | |
| - ein direkter Zugriff auf den Wert der ist ebenfalls moeglich, sollte | |
| aber nicht der Normalfall sein, da die Methoden Nebeneffekte erzeugen | |
| - in bestimmten Faellen kann man den aeusserlich aendernden Zugriff | |
| vollkommen unterbinden (NOSETMETHOD, PROTECT) | |
| (VORSICHT bei mappings/arrays, diese werden bei QueryProp() | |
| als Referenz zurueckgegeben, sind also so aenderbar) | |
| 2. Implementation | |
| ================= | |
| Die Klasse /std/thing/properties.c stellt folgende Funktionen fuer die | |
| Behandlung von Properties bereit: | |
| Normaler Zugriff: mixed SetProp(<name>, <wert>) | |
| - setzt den Wert von <name> auf <wert> | |
| mixed QueryProp(<name>) | |
| - gibt den Wert von <name> zurueck | |
| Direkter Zugriff: mixed Set(<name>, <wert>, <interpretation>) | |
| - setzt fuer <name> einen <wert>: | |
| - den normalen Wert | |
| <interpretation>: F_VALUE (==0) | |
| - eine Methode | |
| <wert>: closure | |
| <interpretation>: F_SET_METHOD, F_QUERY_METHOD | |
| - ein Flag | |
| <wert>: SAVE, SECURED, PROTECTED, NOSETMETHOD | |
| <interpretation>: F_MODE, F_MODE_AS, F_MODE_AD | |
| mixed Query(<name>, <interpretation>) | |
| - fragt fuer <name> einen <wert> ab | |
| - F_SET_METHOD, F_QUERY_METHOD: die Closure/0 | |
| - F_MODE: das (veroderte!) Flag | |
| Global: void SetProperties(<mapping>) | |
| - setzt das Mapping komplett, beachtet >= PROTECTED | |
| mapping QueryProperties() | |
| - fragte das komplette Mapping als Kopie ab | |
| 3. Besonderheiten/Eingebaute Properties: | |
| Existiert zu einer Property eine Funktion mit dem selben Namen und einem | |
| "_set_" bzw "_query_" davor, so wird nicht auf die das Property-Mapping | |
| zugegriffen, sondern es werden die Argumente an diese Funktion uebergeben | |
| und der Rueckgabewert dieser Funktion zurueckgegeben. | |
| Vorteil: | |
| - so kann man Daten, die schnell verfuegbar sein muessen, (bei denen | |
| also Effizienz gegen SetProp/QueryProp spricht) trotzdem nach aussen | |
| einheitlich zugreifbar machen | |
| Nachteil: | |
| - nicht wirklich sauber | |
| - Speichern muss man selbst vornehmen | |
| - Set/Query gehen wie auch bei Methoden an _set_*/_query_* vorbei | |
| - dieses Verhalten sollte der Mudlib vorbehalten bleiben, fuer eigene | |
| Prueffunktionen (wird etwas gesetzt/abgefragt) bzw. Aenderungen | |
| sollte man Methoden (F_SET_METHOD/F_QUERY_METHOD) benutzen | |
| SIEHE AUCH: | |
| SetProp(L), QueryProp(L), Set(L), Query(L), SetProperties(L), | |
| QueryProperties(L) | |
| objekte, effizienz, closures | |
| 21. Maerz 2004 Gloinson |