| Re:Meine Vorschläge |  |
>>Ich habe mich noch mal durch die Threads gelesen und ja auch schon mal kurz etwas Zeit reingesteckt mir die Software anzugucken und auf PHP8 zu hieven (bin dabei in kurzer Zeit erstaunlich weit gekommen, [https://github.com/FrontierPsychiatrist/pxmboard]).
>
>Sehr gut! Ich bin jetzt leider auch nicht mehr tief im Thema (mit PHP 8 schon gar nicht) aber im Endeffekt sind es zwei "größere" Baustellen:
>
>1. Parameterübergabe als Referenz, wie Transistor schon geschrieben hat
Da musste ich ein paar Sachen anpassen weil es anscheinend beim überschreiben von Methoden jetzt so sein muss, dass die Signatur exakt gleich ist. Weil es wiederum nicht möglich ist NULL als Referenz zu übergeben hab ich einfach mal ein paar "&" entfernt, aber das ist ganz klar der Punkt wo genau drauf geguckt werden sollte woe es geht und wo die Referenz wichtig ist. Performance technisch hab ich es so verstanden, dass PHP per Copy on Write macht? D.h. das entfernen von Referenzen wo es aus Performance Gründen gemacht wurde sollte gar kein Problem sein. Interessant ist es nur, wenn die Referenz eben echt modifiziert werden soll. Transistor hat da ja eine kritische Stelle beschrieben.
Generell scheint es aber nicht so zu sein, dass da alle Stellen angepasst werden müssen.
>2. mysql*-Funktionsaufrufe sind alle deprecated und sollten in PHP 8 gar nicht mehr drin sein
Hab ich schon alle durch mysqli* ersetzt, das war schnell und einfach und scheint zu funktionieren.
>Ich glaube, dann gab es noch ein paar Anpassungen bei RegEx Funktionen (ereg(), eregi(), ereg_replace(), eregi_replace()). Das lässt sich aber mit der „Deprecated“-Inspection Funktion in PHP Storm schnell herausfinden.
Es gab noch Probleme damit, dass "each()" nicht mehr existiert, und irgendwas mit magic quotes (auch noch eine Stelle die noch mal genau angeguckt werden muss)
>Und natürlich der Vollständigkeit: Sichtbarkeit der Klassenmethoden. Ich bin mir gerade nicht sicher, ob PHP public/private Deklaration zwingend erwartet, das ist aber dann ja auch schnell angepasst.
Geht ohne public/private, default schein public zu sein. Allerdings müssen static Methoden explizit deklariert werden.
>Wenn man dabei ist, dann lassen sich natürlich auch die Methodenparameter per TypeHinting genauer definieren, dass ist dann natürlich für die Arbeit mit einer IDE ein schöner Vorteil.
Ja, hab das mal ausprobiert und lässt sich super einfach inkrementell hinzufügen.
>Und ich weiß, einen Blumentopf gewinnt man damit nicht, aber PSR4 wäre natürlich auch schön :) Zumal man dann mit einem ordentlichen Namespace auch das ganze via Composer autoloaden kann. Und mit Composer ist es dann natürlich viel entspannter, externe Komponenten einzubinden. Aber zwingend notwendig ist das natürlich nicht, vor allem, wenn Smarty die einzige externe Komponente ist.
PSR4 sagt mir jetzt leider gar nix.
>>Das Maniac Forum wird, vermute ich mal, eine deutlich höhere Lese- als Schreiblast haben. Das könnte man durch einen Caching Layer (Redis?) in der Software ausnuten um DB Zugriffe überhaupt nicht erst stattfinden zu lassen. An so was kann ich auch gerne mitarbeiten. Wenn man den zwischen DB und Templates schaltet profitieren auch gleich die eventuelle JSON API sowie das klassische 3 Frame Rendern davon. Caching kommt natürlich auch immer mit Tücken (Invalidierung...), aber irgendwie denke ich ließe sich das schon handlen.
>
>Ja, das klingt absolut sinnvoll. Aber dafür gibt es mit Sicherheit externe Komponenten, ohne das Rad selbst neu zu erfinden ([https://symfony.com/doc/current/components/cache/adapters/redis_adapter.html]).
Wie schon auch mit K!M besprochen sowieso was, was erst nach gescheitem Messen gemacht werden sollte. Nicht, dass man einen Haufen Arbeit hat um irgendwas 1% schneller zu machen.