| MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | Properties |
| 2 | BESCHREIBUNG: |
| 3 | Im Gegensatz zu Variablen innerhalb eines Objektes, kann man Properties |
| 4 | von aussen veraendern, ohne eine besondere Funktion geschrieben zu haben. |
| 5 | |
| 6 | 1. Das zugrundeliegende Prinzip |
| 7 | =============================== |
| 8 | Das grundlegende Konzept der MUDlib ist, dass wichtige, objektbezogene |
| 9 | Informationen in den sogenannnten Properties gespeichert werden (engl. |
| 10 | property -- Eigenschaft, Eigentum). |
| 11 | |
| 12 | Diese Informationen koennen einfache Werte, wie z.B. Zahlen, Zeichen oder |
| 13 | Objekte, aber auch kompliziertere Strukturen sein. |
| 14 | Jedes Objekt kann beliebig viele solcher Properties besitzen und deren |
| 15 | Namensgebung ist nicht nur auf die von der MUDlib bereitgestellten |
| 16 | Standardproperties begrenzt. Das heisst, das fuer eigene Anwendungen die |
| 17 | Menge der Properties fuer ein Objekt beliebig erweitert werden kann. |
| 18 | Damit sind auch schon die beiden Hauptmerkmale einer Property ange- |
| 19 | sprochen: |
| 20 | |
| 21 | a) ein Name oder Kennung und |
| 22 | b) ein Wert, der durch den Namen repraesentiert wird. |
| 23 | |
| 24 | Das reine Verwalten einer Property mit Namen und Wert ist aber nicht sehr |
| 25 | sinnvoll und so gehoeren zu jeder Property noch zwei weitere wichtige |
| 26 | Dinge. Zu jeder Property wurden jeweils zwei Operationen eingefuehrt, |
| 27 | welche den uebergebenen Wert vor der Speicherung oder Abfrage bearbeiten. |
| 28 | |
| 29 | Zusammenfassend laesst sich das Konzept der Property in folgendem Schema |
| 30 | darstellen: |
| 31 | |
| 32 | +-------------------------------------------+ |
| 33 | | Property | |
| 34 | +-------------------------------------------+ |
| 35 | | privater Datenbereich (Property Werte) | |
| 36 | +-------------------------------------------+ |
| 37 | | Direktzugriff auf den Datenbereich | |
| 38 | +-------------------------------------+ | |
| 39 | | ^ Methoden v | ^ v | |
| 40 | | Setzen | Abfragen | | |
| 41 | +-------------------------------------+-----+ |
| 42 | ^ | |
| 43 | | V |
| 44 | SetProp() QueryProp() |
| 45 | |
| 46 | Aus dem Schema laesst sich Folgendes erkennen: |
| 47 | - beim Setzen und Abfragen wird der Wert einer Methode uebergeben, die |
| 48 | den Wert zurueckgibt oder ggf. die Aenderungen vornimmt |
| 49 | - ein direkter Zugriff auf den Wert der ist ebenfalls moeglich, sollte |
| 50 | aber nicht der Normalfall sein, da die Methoden Nebeneffekte erzeugen |
| 51 | - in bestimmten Faellen kann man den aeusserlich aendernden Zugriff |
| 52 | vollkommen unterbinden (NOSETMETHOD, PROTECT) |
| 53 | (VORSICHT bei mappings/arrays, diese werden bei QueryProp() |
| 54 | als Referenz zurueckgegeben, sind also so aenderbar) |
| 55 | |
| 56 | 2. Implementation |
| 57 | ================= |
| 58 | |
| 59 | Die Klasse /std/thing/properties.c stellt folgende Funktionen fuer die |
| 60 | Behandlung von Properties bereit: |
| 61 | |
| 62 | Normaler Zugriff: mixed SetProp(<name>, <wert>) |
| 63 | - setzt den Wert von <name> auf <wert> |
| 64 | mixed QueryProp(<name>) |
| 65 | - gibt den Wert von <name> zurueck |
| 66 | |
| 67 | Direkter Zugriff: mixed Set(<name>, <wert>, <interpretation>) |
| 68 | - setzt fuer <name> einen <wert>: |
| 69 | - den normalen Wert |
| 70 | <interpretation>: F_VALUE (==0) |
| 71 | - eine Methode |
| 72 | <wert>: closure |
| 73 | <interpretation>: F_SET_METHOD, F_QUERY_METHOD |
| 74 | - ein Flag |
| 75 | <wert>: SAVE, SECURED, PROTECTED, NOSETMETHOD |
| 76 | <interpretation>: F_MODE, F_MODE_AS, F_MODE_AD |
| 77 | mixed Query(<name>, <interpretation>) |
| 78 | - fragt fuer <name> einen <wert> ab |
| 79 | - F_SET_METHOD, F_QUERY_METHOD: die Closure/0 |
| 80 | - F_MODE: das (veroderte!) Flag |
| 81 | Global: void SetProperties(<mapping>) |
| 82 | - setzt das Mapping komplett, beachtet >= PROTECTED |
| 83 | mapping QueryProperties() |
| 84 | - fragte das komplette Mapping als Kopie ab |
| 85 | |
| 86 | 3. Besonderheiten/Eingebaute Properties: |
| 87 | |
| 88 | Existiert zu einer Property eine Funktion mit dem selben Namen und einem |
| 89 | "_set_" bzw "_query_" davor, so wird nicht auf die das Property-Mapping |
| 90 | zugegriffen, sondern es werden die Argumente an diese Funktion uebergeben |
| 91 | und der Rueckgabewert dieser Funktion zurueckgegeben. |
| 92 | Vorteil: |
| 93 | - so kann man Daten, die schnell verfuegbar sein muessen, (bei denen |
| 94 | also Effizienz gegen SetProp/QueryProp spricht) trotzdem nach aussen |
| 95 | einheitlich zugreifbar machen |
| 96 | Nachteil: |
| 97 | - nicht wirklich sauber |
| 98 | - Speichern muss man selbst vornehmen |
| 99 | - Set/Query gehen wie auch bei Methoden an _set_*/_query_* vorbei |
| 100 | - dieses Verhalten sollte der Mudlib vorbehalten bleiben, fuer eigene |
| 101 | Prueffunktionen (wird etwas gesetzt/abgefragt) bzw. Aenderungen |
| 102 | sollte man Methoden (F_SET_METHOD/F_QUERY_METHOD) benutzen |
| 103 | |
| 104 | SIEHE AUCH: |
| 105 | SetProp(L), QueryProp(L), Set(L), Query(L), SetProperties(L), |
| 106 | QueryProperties(L) |
| 107 | objekte, effizienz, closures |
| 108 | |
| 109 | 21. Maerz 2004 Gloinson |