Update doc/efun/ aus Driversourcen.
Manpages der efuns aktualisiert, neue Manpages hinzugefuegt.
Change-Id: I7cc91684269ff56d1aef47d5c5e7c87f7fd531dc
diff --git a/doc/efun/destruct b/doc/efun/destruct
index fd4ab2c..2947aad 100644
--- a/doc/efun/destruct
+++ b/doc/efun/destruct
@@ -1,43 +1,43 @@
SYNOPSIS
void destruct(object ob)
-BESCHREIBUNG
- Zerstoert und entfernt das Objekt ob. Ist ob == 0 (ob wurde schon
- zerstoert), so passiert nichts. Nach dem Aufruf von destruct()
- existieren keine globalen Variablen mehr, sondern nur noch lokale
- Variablen und Argumente.
+DESCRIPTION
+ Completely destroy and remove object ob (if not already done so).
+ After the call to destruct(), no global variables will exist any
+ longer, only local ones, and arguments.
- Wenn sich ein Objekt selbst zerstoert, wird die Ausfuehrung nicht
- sofort abgebrochen. Wird die Efun this_object() aufgerufen, so
- liefert diese 0 zurueck.
+ If an object self-destructs, it will not immediately terminate
+ execution. If the efun this_object() will be called by the
+ destructed object, the result will be 0. Furthermore, all
+ calls to other objects and to simul-efuns will be ignored, instead
+ the driver will return 0 als 'call' result.
- Die meisten Mudlibs moegen es nicht, wenn andere Objekte mittels
- destruct() ins Daten-Nirwana geschickt werden. Stattdessen erwarten
- sie den Aufruf einer speziellen Lfun im zu zerstoerenden Objekt,
- welche normalerweise remove() heisst. Damit kann das zu
- zerstoerende Objekt noch abschliessende Arbeiten im Zusammenhang
- mit seinem Ableben erledigen, wie z. B. die Anpassung des Gewichtes
- seiner Umgebung etc. pp.
+ To keep things consistent, most mudlibs frown upon the
+ destruct()ion of other objects, and instead demand call_others
+ to a specific lfun in the object to destruct (traditionally
+ named "remove"). This will then ensure correct update of e.g.
+ weights, volumes etc. Additionally or instead, the master apply
+ prepare_destruct() can be used for this 'cleanup' functionality.
- Der Interpreter zerstoert das Objekt nicht sofort, sondern er
- markiert es als zerstoert, entfernt es von der Liste, die alle
- Objekte enthaelt, und fuegt es zu der Liste zu zerstoerenden
- Objekte hinzu. Die tatsaechliche Zerstoerung geschieht erst dann,
- wenn keine Referenzen mehr auf das Objekt existieren. Deshalb ist
- es moeglich, dass ein Objekt noch lange nach seiner Zerstoerung
- Speicher belegt, obwohl es von ausserhalb nicht mehr gefunden wird.
+ The interpreter does not really destruct the object
+ immediately, but marks it as deleted, removes it from the list
+ of all objects, and puts it onto a list of to-be-destructed
+ objects. The actual freeing occurs only when all references to
+ a destructed object have gone. Thus it is possible, that an
+ object occupies memory long after it has been destructed,
+ although the object is not visible anywhere anymore from
+ outside.
-BEISPIELE
+EXAMPLES
ob->remove();
- if(ob) // es existiert noch, vielleicht ist die Lfun
- // remove() nicht definiert?
- destruct(ob);
+ if(ob) /* still there, probably ob does not provide remove() */
+ destruct(ob);
- Dies ist die Standard-Methode, ein Objekt zu zerstoeren, ihm aber
- vorher noch die Chance zu geben, es selber zu tun.
+ This is a way of destructing an object but giving it a chance
+ to do it by itself.
-GESCHICHTE
- LDMud 3.2.7: 0 (zerstoerte Objekt) als Argument annehmen.
+HISTORY
+ Changed in 3.2.7 to accept destructed objects as argument, too.
-SIEHE AUCH
- clone_object(E), remove(A)
+SEE ALSO
+ clone_object(E), remove(A), prepare_destruct(M)