Quadaptor

Wie würdest du dir diese virtuellen Doc-Tags vorstellen? Denn immerhin gibt es schon ein Haufen von Tags und diese müssten dann allesamt auf die gemeinte Eigenschaft assoziert werden. Das würde auch einen zieemlich langen Doc-Comment geben. Trägt dann auch nicht so zur Übersichtlichkeit bei.

Einen langen Doc-Block bei Änderungen zu aktualisieren ist wahrscheinlich auch kein Vergnügen und ist dann für falsche Vervollständigungen verantwortlich.

isset() benötigst du eigentlich niemals, sofern du eine festdefinierte Schnittstelle hast. Dann weißt du nämlich, dass es die Eigenschaft bzw. die Methode gibt.

Ja genau, dann hätte man in dem genannten Falle wirklich 40 Methoden. Sinnvollerweise (je nach Kontext) per Interface definiert - inkl. der jeweiligen Rückgabewerte und möglichen Ausnahmen, was wiederrum per Unittest dauerhaft sichergestellt werden kann.

Verwendest du Eigenschaften anstatt Methoden läufst du außerdem noch Gefahr, dass ein internes Refactoring deutlich schwerer durchführbar ist, denn a) kannst du nicht weiterhin auf deine Unittests setzen und b) dürften sich die Namen der Eigenschaften nicht ändern, was aber durchaus mal notwendig sein kann - man weiß nie, was für neue Strukturen notwendig sind. Verwendest du Methoden hast du zwei Sicherheiten: Interfaces und Unittests, die beide bei einem Refactoring unverändert bleiben (müssen), um auch wirklich sicherzustellen, dass hinterher alles genaus funktioniert, wie vorher.

Mister Ad

Manko10

Ich glaube, das Thema hat nur noch bedingt etwas mit Goto in PHP 6 zu tun (beides gehört in den Bereich Programmierung. ).
Vielleicht sollte man dazu einen neuen Thread aufmachen.
Wenn man versucht, den Thread objektiv zu betrachten, so stellt man fest, dass sich jetzt alle Beteiligten (mich eingeschlossen) gegenseitig nur noch an der Frage aufhetzen, was einer objektorientierten, wartbaren, wiederverwendbaren und erweiterbaren Systemarchitektur am ehesten nahe kommt.
Aber mal ehrlich: gibt es für solche Sachen nicht UML? Wenn man vor dem Losprogrammieren das gesamte System durchmodelliert (einschließlich Klassen und Interfaces), so wird man doch wohl in den allermeisten Fällen merken, welche Methodik nun am besten zum Einsatz kommt und welche gleich ausscheidet.

Ich würde mal sagen, das Thema gleitet langsam in die Bereiche ab, in denen man sich eh nie einigen wird. Programmierer sind nunmal ein zerstrittenes Volk, das erst in einem gemeinsamen Projekt (zumindest zeitweilig) geeint werden kann.

Quadaptor

Stimmt, UML und Magic Methods ist kaum zu vereinbaren. Ich kenn zumindest kein UML-Tool das irgendwelche Magic-Sachen unterstüzt, geschweige denn auch Magic-Code erzeugt.

Manko10

Ob ein UML-Tool das unterstützt, ist weniger relevant.
Wichtiger ist, dass die UML-Spezifikation das Magic-Gedöns unterstützen muss.
Ich denke, dass eine Magic Method letztendlich als ganz normale Methode modelliert würde (evtl. mit Kommentaren versehen). Ob sie ihren Zweck erfüllt oder ob es nicht vielleicht auch auf andere Weise ginge, wird man dann sehen.

Quadaptor

Ich denke und hoffe, dass es niemals so weit kommen wird, da aus genannten Gründen, Magic Methods die API verhunzen.

Mit einem ordentlichen Schnittstellendesign steht und fällt eine Applikation, das *sollte eigentlich* jedem bewusst sein.

Manko10

Super, dann bist du ja zu einem Punkt gekommen, ich gebe dir einen Keks und wir alle wissen, dass wir __get(), __set() und __call() weiterhin nicht verwenden sollten.
Nee, im Ernst: modellierbar wäre es, aber sinnvoll wohl nicht.

Chriz

Amen.

__________________
"Nuschel ich?" - "Was?"