Querdenkender Webworker mit WordPress-Affinität

Vergessen lassen

Ich habe heute damit begonnen, die ersten Artikel zu löschen, die es tatsächlich geschafft haben, hier älter als 6 Jahre zu werden. “Ihr Dasein gefristet haben” wäre fast die treffendere Formulierung, denn der Informationswert der Texte war durch das “Reifen” hier im Blog bedenklich tief gesunken. Weitere Aktionen dieser Art werden sicher folgen.

Schon vor Ewigkeiten begannen ja die Diskussionen darüber, wie man damit umgeht, dass das Netz theoretisch nichts vergisst, soll doch das Vergessen eine der wichtigsten Eigenschaften des menschlichen Gedächtnisses darstellen, um beispielsweise das Lernen als solches überhaupt erst zu ermöglichen, indem veraltete oder irrelevante Informationen durch neue oder korrigierte Erkenntnisse überlagert werden.

Der Auslöser für eine dieser wellenartig heranschwappenden Debatten war, wenn ich mich richtig erinnere, die Art und Weise wie Twitter mit älteren Tweets umgeht bzw. wie der Dienst Kurznachrichten “vergisst”, die ihre Haltbarkeitsdauer überschritten haben.

Spätestens zu diesem Zeitpunkt war aber wohl jedem klar, dass es Twitter hierbei wohl eher um die Qualität des eigenen Services ging. Folgt man nämlich Links von Tweets, die vor mehr als 3 Jahren verbreitet wurden, bekommt man oft genug die Fehlermeldung eines Servers anstelle der erhofften Information zu sehen.

Wer Informationen zu dieser Thematik sucht, kann leicht den Eindruck gewinnen, dass es sich hierbei um irgendetwas etwas handelt, was uns gerade verloren geht, etwas das bewahrt werden muss. Ein dunkles Zeitalter wird heraufbeschworen, das später von keinem Historiker mehr rekonstruiert werden könne. Ich sehe das Netz nicht als ein Archiv.

Für das Bewerten und Konservieren von Informationen dürfen sich – nach meinen Empfinden – gern andere verantwortlich fühlen.

Um den Prozess des Vergessens hier in meinem Blog nicht so dramatisch zu gestalten, dass er einer durch einen Unfall verursachten Amnesie gleicht, gibt es nun einen Abriss der Inhalte, die von nun an einen exklusiven Platz in meinen Backups haben werden:

In extract () und include () habe ich PHPs extract gedisst. Grundsätzlich ist gegen den Befehl nichts einzuwenden, wenn der Verstand eingeschaltet war, während man die Variablen eines Arrays in die aktuelle Symboltabelle importiert. Man sieht das bei WordPress, wenn man sich die Beispiele der Shortcode API ansieht. Wenn man aber weiß, dass auch andere noch den eigenen Unfug lesen müssen, kann man sicher auch vermeiden, Variablen magisch erscheinen zu lassen.

In dem Post Hände weg von array_key_exists () habe ich mich über ein weiteres PHP-Ungetüm  aufgeregt, welches zu diesem Zeitpunkt ein echter Performance-Killer war. Ich weiß nicht, wie das heute ist, weil ich mich nach wie vor lieber an isset halte. In den Kommentaren (ja, auch die wurden gleich mit gelöscht) wurde ich darauf hingewiesen, dass man mit array_key_exists auch Items finden könnte, die den Wert null enthalten würden. Allerdings ist mir der Sinn nach all den Jahren immer noch nicht klar.

Die beiden Artikel Laß uns doch ‘nen Counter bauen und Upgrade Apache 2.2 waren genau solche Museumsfundstücke, die ihre Haltbarkeitsdauer bereits lange überschritten hatten. Hier lohnt sich auch kein Nachwort mehr.

Der Post “sort” liefert ein “bool” – warum auch nicht? hingegen, ist an sich immer noch interessant. Allerdings war die Reaktion auf meine Gedanken darüber, dass nicht nur der Name einer Funktion ein implizit gegebenes Versprechen halten müsse, sondern auch sein Rückgabewert konsistent sein sollte, (sagen wir mal) eher zurückhaltend.

Der Artikel MySQL und PHP – Trenn das mal! beschrieb auch eher die Situation von vor fünf Jahren. Heute ist das ja mit Klassen wie wpdb kein Thema mehr. Führt man die selbe Diskussion aber auf einem etwas allgemeineren Level, geht es eigentlich mehr um das Trennen von Logik und Design. Allerdings ist auch das nicht mehr ganz so einfach, wenn man an sich heutige Frameworks anschaut, welche den Code sogar in Modell, Präsentation und Steuerung organisiert haben wollen, Template-Klassen für die Ausgabe bereitstellen, was viele Applikationen in ihrer Gesamtheit weitaus komplexer (allerdings auch leistungsfähiger) macht.

Zu guter Letzt musste auch der Post Slots in PHP wie in Python? “dran glauben”. Slots sind ja eher nicht so eine typische Geschichte in Python. Damals habe ich meine ersten Gehversuche mit dieser Programmiersprache gemacht und würde ich noch einmal vor die Wahl gestellt, gäbe es eine große Chance, dass ich  ich mich eher auf Python als auf PHP konzentrieren würde.

Have fun!

Das könnte Dich auch interessieren:

Ihre Meinung ist uns wichtig

*