Goto in PHP6

[Chrissi]

Moin,

hab gefunden, dass goto anscheinend in PHP6 eingeführt werden soll.
Zu sehen hier: PHP: Liste der reservierten Wörter - Manual
Goto ist als reserviert in PHP6 eingetragen.

Meine Frage ist jetzt: Wozu braucht man son Müll, der vor Jahrzenten mal üblich war?

(mal nen Zitat dazu ausm Chat..)

(21:56:2 (Ryuzaki) hm... das mit dem goto in php is schon seltsam...
(21:56:47) (matze|) du bist seltsam
(21:56:50) (Ryuzaki) was soll man mit dingen, die vor 30 jahren ueblich waren?...
(21:57:00) (@Chrissi) jop
(21:57:41) (@Chrissi) naja, hoffen wir mal, dass sie irgendwas innovatives dabeigebastelt haben, um nen grund für den einbau von goto zu haben...
(21:57:42) (Ryuzaki) ich glaub, da ham die php-entwickler muell gebaut ^^

Gruß
Chrissi

(hoffentlich im richtigen Forum gepostet...)

[Chriz]

Amen.

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

[Quadaptor]

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.

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]

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]

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]

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]

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.

[Chriz]

Wenn du andere beleidigst, wird deine Argumentation auch nicht besser.

Nein ich schreibe setter/getter nicht selbst, da ich wie gesagt keine setter/getter verwende. Das laesst sich in den Templates des Code-Generators allerdings umstellen, um auch deine naechste Frage zu beantworten.

Die Auto-Vervollstaendigung fehlt natuerlich in der IDE, was ein klarer Nachteil ist. Deshalb koennte man ja daruber nachdenken, Documentator-Auszeichnungen oder virtuelle Deklarationen einzufuehren.

Wofür isset? Du hast Schnittstellen...

Was meinst du? (wenn du wieder persoenlich wirst, mach ich den Thread zu, keinen Bock auf sowas)

Geil, wenn du 20 Eigenschaften hast, die neue Logiken bekommen sollen, dann machst du einen Switch auf 20 Eigenschaften? Oder leitest du einfach mal alle Eigenschaften auf __call-Methoden um? Gibts Whitelisten? Über testbare Software musst du noch viel lernen.

Soll ich mir stattdessen 40 Setter/Getter generieren lassen, obwohl nur 2-4 mehr als Lese/Schreib-Logik benoetigen? Ich teste bei __set/__get ob es eine protected Set#Property#/Get#Property# Methoden gibt und rufe diese dann auf. Interfaces benutze ich auch wenn sie Sinn machen.


So und jetzt kannst du das letzte Wort haben.

[Quadaptor]

Ja, aber verwechsel doch Faulheit nicht mit Komfort.

Welchen Komfort bietet denn __*? Schreibst du getter-/setter-Mehoden etwa selbst? Dann mein Beileid... Außerdem: Wie geht deine IDE damit um? Autovervollständigung? Pustekuchen... Wo ist nun der Komfort?

Warum soll ich fuer eine Eigenschaft jeweils zwingend eine Setter- und eine Getter-Methode schreiben (oder eine dritte um __isset zu ersetzen), um die gleiche Flexibilitaet wie mit __set/__get zu erreichen?

Wofür isset? Du hast Schnittstellen...

Vielleicht weiss ich noch garnicht, ob ich beim Setzen oder Laden der Eigenschaft mehr Logik benoetige.

Beispielsweise mussten die Kreditkartendaten in der Datenbank verschluesselt werden. Ich habe dazu einfach die setter/getter Methode der Billing-Klasse erweitert, so dass Werte beim Setzen automatisch mit Mcrypt verschluesselt werden und beim Lesen automatisch wieder entschluesselt. Das Programm musste sonst nirgends geaendert werden. Das war ein Ding von 15 Minuten.

Geil, wenn du 20 Eigenschaften hast, die neue Logiken bekommen sollen, dann machst du einen Switch auf 20 Eigenschaften? Oder leitest du einfach mal alle Eigenschaften auf __call-Methoden um? Gibts Whitelisten? Über testbare Software musst du noch viel lernen.

Natuerlich waere das gleiche auch mit expliziten Setter/Getter Methoden moeglich gewesen, aber wie gesagt, dann muessen sie auch fuer jede Eigenschaft angelegt werden um gleichaufzuziehen.

Stimmt, aber ohne die ganzen Nachteile von __*.

Verwendest du eigentlich jemals Interfaces?

[Chriz]

Natürlich, der Hauptnutzen besteht darin, dass man einfach faul ist, klar.

Ja, aber verwechsel doch Faulheit nicht mit Komfort. Warum soll ich fuer eine Eigenschaft jeweils zwingend eine Setter- und eine Getter-Methode schreiben (oder eine dritte um __isset zu ersetzen), um die gleiche Flexibilitaet wie mit __set/__get zu erreichen? Vielleicht weiss ich noch garnicht, ob ich beim Setzen oder Laden der Eigenschaft mehr Logik benoetige.

Beispielsweise mussten die Kreditkartendaten in der Datenbank verschluesselt werden. Ich habe dazu einfach die setter/getter Methode der Billing-Klasse erweitert, so dass Werte beim Setzen automatisch mit Mcrypt verschluesselt werden und beim Lesen automatisch wieder entschluesselt. Das Programm musste sonst nirgends geaendert werden. Das war ein Ding von 15 Minuten.

Natuerlich waere das gleiche auch mit expliziten Setter/Getter Methoden moeglich gewesen, aber wie gesagt, dann muessen sie auch fuer jede Eigenschaft angelegt werden um gleichaufzuziehen.

[Manko10]

Ich sehe hierbei keinen Vorteil gegenüber folgendem:

private _myProperty;

public function setProperty($value)
{
    $this->_myProperty = $value;
}

public function getProperty()
{
    return $this->_myProperty;
} 

Intern bietet es keinen Vorteil. Von außen aber kann man direkt auf Eigenschaften zugreifen, ohne auf die Vorteile eines Getters oder Setters verzichten zu müssen. Es ist auch möglich, durch Weglassen eines Zweiges ReadOnly- oder WriteOnly-Attribute zu erstellen.
Ob man es für sauber hält und gern einsetzt oder nicht, muss dann jeder für sich entscheiden.
Ich denke, für einige generelle Konfigurationen wäre es durchaus sinnvoll.
Ich meinte das jetzt nicht so, dass man allgemein alle Attribute public macht, was ja wirklich etwas ...ähh... seltsam wäre. Eher so, dass man wichtige Eigenschaften, für die man bisher gezielt Getter- und Setter-Methoden eingesetzt hat, so verpacken könnte. So z.B. Konfigurationsvariablen für Datenbank-Klassen.
Alles andere, von dem der Client eh nichts Direktes mitbekommt, sollte weiterhin private sein.
Das Argument mit Interfaces ist aber natürlich schlagkräftig.

Welche Verwirrung? Jetzt bin eher ich verwirrt.

Mit Verwirrung meine ich die Unübersichtlichkeit, die durch die alleinige Verwendung dieser Inzeptor-Methoden entsteht. Immerhin ist es schlecht zu dokumentieren, was alles durch __get(), __set() und __call() implementiert wird und was nicht implementiert sein soll (wurde bereits in diesem Thread diskutiert).

[Quadaptor]

...würde eher Property-Deklarationen wie in C# begrüßen. Neben der einfachen Deklaration, wie man es sonst auch gewohnt ist, gibt es noch dieses:

private double _myProperty;
public double myProperty {
    get {
        return _myProperty;
    } set {
        _myProperty = value;
    }
}

Ich sehe hierbei keinen Vorteil gegenüber folgendem:

private _myProperty;

public function setProperty($value)
{
    $this->_myProperty = $value;
}

public function getProperty()
{
    return $this->_myProperty;
} 

So besitzt man Getter und Setter, muss sich aber nicht mit der Verwirrung von Lazy-Initialisation abgeben.

Welche Verwirrung? Jetzt bin eher ich verwirrt.

Die C#-Methode finde ich recht hässlich, weil sie nicht API-sicher. Meiner Ansicht nach, dienen Eigenschaften ausschließlich zur internen Datenspeicherung, während Methoden den Zustand der Klasse manipulieren. Deshalb sind meine Methoden öffentlich, Interfaces eben, während die Eigenschaften meiner Klasse entweder private oder höchstens protected sind.

EDIT: Klassen kappseln Eigenschaften. Nach außen sollen diese Eigenschaften geheim bleiben, weil diese sich schnell mal ändern können. Schnittstellen ändern sich weniger häufig bzw. sollten sich nicht ändern, von daher sind keine Eigenschaften öffentlich, da ich so beliebig intern refactoren kann und mich einfach nur an die Schnittstelle halten muss.

[Manko10]

Also theoretisch müsste man ein White-List-Array in solchen Inzeptor-Methoden haben ("solche", weil Inzeptor-Methoden ja nicht generell schlecht sind - __construct() ist ja z.B. auch eine). Bloß könnte man dann genausogut eine direkte Implementierung vornehmen.
Wie ich schon schrieb, halte ich __get(), __set() und __call() für ziemlich unsinnig und würde eher Property-Deklarationen wie in C# begrüßen. Neben der einfachen Deklaration, wie man es sonst auch gewohnt ist, gibt es noch dieses:

private double _myProperty;
public double myProperty {
    get {
        return _myProperty;
    } set {
        _myProperty = value;
    }
}

So besitzt man Getter und Setter, muss sich aber nicht mit der Verwirrung von Lazy-Initialisation abgeben.

[Quadaptor]

Was du von Hand machst uebernimmt halt __call, wo ist jetzt genau der Mehrwert?

Du kannst dir selbst deine Fragen beantworten:
a) Wie dokumentierst du __call-Methoden?
b) Wie spezifizierst du __call mit Interfaces? => Wie schützt du dich vor API-Änderungen?
c) Was passiert, wenn jmd. fälschlicherweise (z.B. durch Tippfehler) eine Methode aufruft, die es nicht gibt. Ich glaub nicht, dass all deine __call's eine Exception rauswerfen - aber wenn doch, hast du genauso viel Aufwand wie ohne __call.
d) Unit-Tests - auf dynamische APIs? Sehr geil...