Thema:
Re:Meine Vorschläge flat
Autor: Fieldy
Datum:23.02.22 15:44
Antwort auf:Re:Meine Vorschläge von Sylvester

>>>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.

Das ist gut, dann ist das ja auch schnell gemacht bzw. lässt sich ja dann auch gut die entsprechenden Stellen testen, ob es weiterhin funktioniert.

>>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.


Ja genau, default ist public. Wenn es ohne geht, dann kann man das auch nach und nach anpassen. Ich glaube nicht, dass das Vorhandensein der public/private Deklarationen Auswirkung auf die Performance haben wird.

>>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.


Ja, das ist jetzt nichts, was direkt für den Wechsel auf PHP 8 zwingend notwendig ist.

>>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.


PSR ist eine Sammlung an Code Conventions zu verschiedenen Themen. Es gibt z.B. PSR2, welche generelle Formatierungsregeln beinhaltet. PS4 ([https://www.php-fig.org/psr/psr-4/]) hingegen definiert, wie eine Klassen- und Ordnerstruktur aufgebaut sein muss, damit alle Dateien via Composer im Autoloader geladen werden können. Composer ist der Paketmanager für PHP ([https://getcomposer.org/doc/01-basic-usage.md] ).

Damit entfällt das manuelle Laden von Daten via include() da alle Dateien bereits geladen sind. Die gängigen PHP Frameworks (Symfony & Laravel) sind nach dem Konstrukt gebaut und sowohl das Framework als auch manuell erstellte Klassen stehen zur Laufzeit direkt zur Verfügung. Die Konfiguration erfolgt über eine JSON-Datei, in der auch weitere externe Komponenten sehr komfortabel der eigenen Anwendung hinzugefügt werden können ([https://github.com/laravel/laravel/blob/9.x/composer.json])

>>>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.


Ja, das macht absolut Sinn :)


< antworten >