Hallihallo!
Mein Destruktor schließt am Ende des Arbeitstages lediglich das Zeug vom Schreibtisch in den Schrank ein. Deiner aber nimmt vorher auch noch den Stapel der erzeugten Geschäftsbriefe, tütet sie in Umschläge, frankiert diese und legt sie in den Postausgang.
Nein, das tut er nicht :-)
Ich stelle fest, dass ich anscheinend kein guter Erklärbär bin...Vielleicht hast du auch mein Beispiel nicht so verstanden, wie ich es meinte.
Dem entnehme ich, dass der Destruktor genau das macht, was ich meinte. Er räumt nicht einfach nur die Arbeitsmittel weg sondern tütet entstandene Daten ein und versendet sie.
Ich habe über genau diesen Satz nochmal gründlich nachgedacht, und dabei festgestellt, dass ich Dich tatsächlich falsch verstanden hatte. Ich dachte die ganze Zeit, Du meinst mit dem "Eintüten" das Sortieren der Logeinträge, und mit dem Versenden das Verteilen an die verschiedenen Empfänger (was in meinem Fall die Mail an den Nutzer, die Mail an den Admin und die Datei im Logverzeichnis war).
Jetzt, da ich Deinen Einwand verstanden habe, sieht die Sache anders aus
Vielleicht siehst Du dann, dass er im Endeffekt genau das tut, was Du vorgeschlagen hattest, nur anders verpackt:
Was ich da vorgeschlagen hatte war Teil des Arbeitsvorgangs und nicht Teil des Aufräumens.
Japp, das sehe ich jetzt auch. Ich halte das für verständlich, was Du da meinst, aber nicht für gut.
Die Klasse log: (bedenke bitte, sie hat noch die Versionsnummer 0.0.2, ist also durchaus verbesserungswürdig! Zum Beispiel sind konkurrierende Zugriffe auf logfiles noch nicht bedacht...
Das Logfile ist die ganze Zeit offen und müsste damit alle anderen Prozesse blockieren. Du öffnest also den Postausgang und blockierst ihn für alle anderen. Oder in deinem Beispiel, du öffnest den Safe und hast tagsüber auch noch ein Sicherheitsproblem geschaffen.
Genau dieser Einwand ist der Grund, weshalb ich es mir nicht verkneifen konnte, hier nochmal zu antworten.
Das Logfile ist nämlich NICHT die ganze Zeit offen, sondern nur während der Laufzeit des Destruktors! Der Fall, den Du vielleicht meinst, tritt nur dann auf, wenn beim Erstellen des Objekts ausdrücklich $paranoia gefordert ist. In den Kommentaren habe ich sogar extra geschrieben, dass man das eben NICHT tun soll (Kommentare sind doch keine Anwender-Dokus, oder? *SCNR*). Eingebaut ist diese Option lediglich für die Phase des Debuggens, damit ich auch im Falle eines fatalen Fehlers sehen konnte, was Phase war. Also nochmal: während der Lebenszeit des Log-Objekts werden nur Daten gesammelt und sortiert (auf seinen Schreibtisch geworfen), und wenn es Feierabend macht (__destruct), heftet es seinen bereits sortierten Papierkram in eine Akte und stellt sie in den Schrank (Datei speichern).
Vielleicht wirst du, um dieses Nebenläufigkeitsproblem zu lösen, wirklich auf meinen Vorschlag eingehen und jede Log-Zeile einzeln schreiben - was unter Umständen auch nicht so toll ist, und einen Dateihandlings-Overhead mit sich bringt, auch wenn der in der Funktion file_put_contents() versteckt ist.
Genau wegen dieses Overheads habe ich diesen "Aufwand" ja betrieben. Ich wollte ihn nicht, weil er das ganze System elend langsam macht, und ausserdem voneinander völlig unabhängige Requests in einer einzigen Datei wild durcheinander mixt. Und komm´ mir jetzt nicht mit "jeder Request seine eigene Datei" ;) Das war mein erster Versuch, und er war widerlich langsam und das Chaos war unbeschreiblich...
Besonders auf meinem Raspi kämpfe ich hier nicht um Millisekunden, sondern um Sekunden. Das Nebenläufigkeitsproblem habe ich übrigens flock für mich lösen lassen. Dafür wurde es schliesslich erfunden :-)
Wir müssen das jetzt nicht weiter ausdehen, denn anscheinend kommen wir hier nicht auf einen grünen Zweig.
Da stimme ich mit Dir überein. Ich wollte eigentlich auch die Klappe halten, aber Deine falsche Analyse meines Quelltextes wollte ich so nicht im Raum stehen lassen :-)
Beste Grüsse, und ein schönes Wochenende,
Tobias Hahner