Mailinglisten-Archive |
> z.B., weil mit der "Vernichtung" des Objektes noch andere > Aufraeumaktionen einhergehen sollen. Denkbar waere z.B., Unterobjekte > ebenfalls zu loeschen oder gar noch irgendwelche in Verbindung mit dem > Objekt gelockten Datensaetze in einer Datenbank wieder freizugeben. Das genau ist eben nicht garantiert. >Bei der ueblichen Laufzeit > eines PHP-Scripts mitunter auch nich unbedingt noetig. PHP-GTK, VL-SRM > Das ist die klassische Aufgabe eines Destruktors. Ressourcen, die > waehrend der kompletten Lebenszeit des Objektes gebunden sein muessen, > wieder freizugeben. Bezweifelt ja auch keiner. Nur macht dies allein für Sprachen/Implementierungen Sinn, bei der die Vernichtung eines Objekte auch mit der Freigabe aus dem Speicher korrespondiert. Und das ist heute kaum noch der Fall. Mittlerweile wird bei der Vernichtung eines Objektes, das Objekt lediglich erstmal aus dem Variablenpool geworfen. Erst wenn tatsächlich Not am Mann ist(=Speichermangel) oder der Computer idlet gerade, wird der Destruktor aufgerufen und der Speicher freigegeben. Und wann das ist und was in der Zwischenzeit passiert (Session-Timeout, Absturz etc.) weisst du nicht. Sollten Destruktoren in ZE2 tatsächlich implementiert werden und am Scriptende automatisch ausgeführt werden, gibt es ein ganz erhebliches Problem: --------- class Evil { function __construct() { // mach was } function __destruct() { // mach was was 30 min dauert } } $bart = new Evil ; --------- Was passiert? PHP initialisert ein neues Objekt und das Script wird danach beendet. Da Variablen am Ende automatisch zerstört werden, wird vorher *unabhängig* vom Script-Timeout der Dekonstruktor ausgeführt und der darf dann solange rödeln wie er will.
php::bar PHP Wiki - Listenarchive