Sven Rautenberg: eval nicht mit mehrdimensionalen Arrays möglich?

Beitrag lesen

Moin!

Als Negativpunkt kann ich den Codestyle erwähnen.

Coding Style ist oftmals eine Frage der persönlichen Preferenz.

Nicht, wenn man sich in Universen bewegt, in denen sie vorgeschrieben werden.

Es ist Usus, sämtliche Methoden, die nicht public sind, mit einem Unterstrich beginnen zu lassen. Daran sollte man sich halten, es macht das Codelesen deutlich leichter.

Und __construct() sowie andere Magic Methodes müssen demnach immer nicht public sein?

Nein, diese magischen Methoden haben eine Sonderstellung - außerdem beginnen sie ja auch mit ZWEI Unterstrichen.

Die Unterstrichregel ist nicht sinnvoll bei als protected ausgezeichneten Mitgliedern, denn die können in einer abgeleiteten Klasse zu public umdeklariert werden und dann stünden sie da mit ihrem Unterstrich und verwirrten dich beim Codelesen.

Wenn ich SOWAS tue, habe ich sowieso Probleme mit meinem Code, nicht nur beim Lesen.

Ich hab das gerade mal ausprobiert: Funktioniert unerwarteter Weise tatsächlich - würde ich allerdings nie so realisieren.

Wenn ich eine Klasse erweitere, und eine als protected vererbte Methode neu als public implementiere, dann bringt mir das erstmal keinerlei Vorteile, wenn ich den Namen beibehalte. Sprich: Ich kann genausogut auch einen neuen Namen vergeben, ohne Unterstrich. Denn die neue Methode ist ja einfach so aufrufbar, ohne automatisch irgendwie die vererbte Methode aufzurufen.

Und der Zugriff auf die vererbte Methode ist in beiden Fällen mittels parent:: möglich, es kommt also nicht zwingend darauf an, dass die neue Methode den gleichen Namen besitzt.

- Sven Rautenberg