nicht angemeldet
Tach!
In PHP hingegen sind viele Funktionsaufrufe, mitunter ein Performanceproblem, was man vermeiden kann, wenn es sich sowieso nur um 1:1-Durchreichungen an die internen Variablen handelt und keinerlei Zugrifflogik dabei irgendwas regelt. Zur Not kann man mit den Magic-Methoden __get/__set immer noch Getter/Setter gezielt für die das benötigenden Werte implementieren, ohne dass sich die API ändert.
Die Sätze enthalten Dinge, die ich als falsch betrachte und deshalb kommentieren muß:
Erstens: Es ist egal, wie man es implementiert, dass es Getter und Setter gibt - WENN man sie nachträglich hinzufügt, ändert sich die API, und wenn man irgendeine Typprüfung in die Magic-Methoden einfügt, ändert sich die API auch.
Und zweitens sind die Aufrufe über die Magic-Methoden deutlich unperformanter, als wenn man konkrete Funktionen bzw. Eigenschaften implementiert hat. Du vergleichst beides zwar nicht, aber dein Eingehen auf Performance zu Beginn und die Verbindung "zur Not kann man Magic-Methoden" implizieren mit diesem Vorgehen keine Performance-Einbußen.
Als "zur Not" betrachte ich den Fall, dass man aus gewichten Gründen nicht von Eigenschaftenzugriff auf Zugriffsmethode wechseln kann, wenn nachträglich ein Bedarf für eine Zugriffslogik festgestellt wird. Dann wäre für diesen einen (oder anderen) Fall der Notnagel Magic-Get/Set eine Option. Ich sehe da grad nicht, wo du eine API-Änderung siehst. Vorher war es $foo->bar = 'qux'; und nachher ist es das immer noch. Die Performanceänderung sollte sich im Rahmen bewegen, ich plädiere ja nicht dafür, alles auf Magie umzuschreiben, sondern nur die "Notfälle". Und das sollte letztlich immer noch performanter sein, als alles mit unfunktionalen Gettern/Settern zuzupflastern. Außerdem bewegt sich der Unterschied im Bereich der Mikrooptimierung.
dedlfix.