PHP 8.2: Deprecated: Creation of dynamic property [...] is deprecated
Wat mij in het begin niet direct duidelijk was, is het verschil in 'verwijsbriefjes' of references. Als je in Rust een object aanmaakt in een variabele, bevat die volgens de compiler het object zelf, en juist niet een verwijsbriefje zoals in PHP.
Rust:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
struct A {}
fn doe(a: &A) {}
fn main() {
let a = A{}; // maak object
doe(a); // geeft fout
}
fn doe(a: &A) {}
fn main() {
let a = A{}; // maak object
doe(a); // geeft fout
}
PHP:
Daarna ging ik kijken wat je nog meer kan doen in PHP wat niet kan in Rust, zoals de functie aanroepen met verschil in hoofd- en kleine letters, een extra variabele aanmaken met hetzelfde verwijsbriefje, en het instellen van dynamische eigenschappen:
Code (php)
Het enige waarbij PHP mij als programmeur helpt is: "Warning: Undefined variable $a"
Maar sinds PHP 8.2rc1 komt daar deze melding bij:
"Deprecated: Creation of dynamic property A::$eigenschap is deprecated"
Dat scheelt bij het debuggen bij typfouten. Nu heb ik een class "cObject" waarop elk object moet extenden met daarin de __call() functie. Alleen zo krijg je in PHP 8.1 en eerder een melding bij een typfout.
Ligt het aan mij of gaat PHP de betere kant op?
Of zou het aan mij IDE (Eclipse PDT) liggen dat die voor dat soort dingen geen melding geeft? (Zijn er IDE's die dat wel doen?)
Je hoort te pas én te onpas dat je composition over inheritance moet prefereren, maar ik kan ook wel uitzonderingen bedenken. Ik ben daarom wel benieuwd wat die in jouw specifieke geval zijn.
Zelf ben ik afgestapt van bijna dwangmatig getters en setters gebruiken omdat PHP nu strict typing goed ondersteund. Waar jij vijf parameters doorgeeft aan één functie, zou ik nu eerder een apart value object gebruiken.
De code moet naar Rust, om het als objectcode bij de klant te kunnen stallen.
Met open code in PHP blijft je bedrijfsgeheim niet veilig bewaard, en kan je het product alleen als SaaS aanbieden.
Daarbij ben je als SaaS provider verwerkingsverantwoordelijke, en daarvoor zou mijn organisatie eerst NEN-7510 gecertificeerd moeten zijn. Daar moet budget voor vrijgemaakt en het hele traject duurt even. SaaS is vooralsnog geen optie helaas.
Daarbij zag ik de truuk met de magic __call() functie bij een klein framework, en ik vond dat wel een goed idee. Elke class moest de "cObject" class wel extenden, vanwege dat PHP bijna alleen maar weak types kent, waardoor het niet mogelijk was om een geinstantieerde class als "object" te herkennen. Inmiddels wordt ook dat wel wat beter in PHP 8, in plaats van vage "resources" t/m PHP 7 komen er veel meer verschillende objecten (en dat breekt bestaande code weer, maar daarvoor zijn unit tests).