"5 Strengths of PHP"

[Sven Rautenberg]

Moin!

In Kombination mit Dereferencing, können wir Method-Chaining benutzten. Stell dir eine Liste von Produkten vor, wir wollen den Gesamtpreis ermitteln:

gesamt = produkte.map( getPreis ).reduce( sum );

In prozeduraler Schreibweise sähe das so aus:

gesamt = reduce( map( produkte, getPreis ), sum );

Es gibt einen einfacheren Weg:

gesamt = produkte.gesamtpreis();

Ja, natürlich ist das Cheaten. ;)  Ich will illustrieren, dass ihr eventuell (aber wirklich nur eventuell) auf einem Low-Level-Niveau der Bearbeitung von Datenstrukturen Recht habt, aber ab einem gewissen Abstraktionsgrad wird es irrelevant, wie schön lesbar die Low-Level-Operationen sind, weil man vermutlich keine komplexe Applikation mehr auf Assembler-Niveau schreiben würde.

Und an der Stelle ist es dann interessant, welche eigenen, nutzbringenden höheren Funktionalitäten man braucht und anbietet, und wie sich diese benutzen lassen.

Es geht hier nicht um die Notation, sondern um die Semantik. Für eine Menge macht es zum Beispiel Sinn Methoden für Vereinigung und Durchschnitt zur Verfügung zu stellen. Bei einem Tupel ergeben diese Methoden wenig Sinn. Dafür könnte man für ein Tupel aber zum Beispiel eine Methode implementieren, die einem die Position eines Elements zurück gibt, für die Lotto-Zahlen wäre das zum Beispiel recht nützlich.

Das Argument spielt sich augenscheinlich ausschließlich auf Datenstrukturebene ab. Natürlich sind Datenstrukturen nicht überflüssig oder irrelevant, aber nach meiner Wahrnehmung ist der relevantere Teil die einer Applikation innewohnende Businesslogik.

Und auf diesem Level gedacht wird man sich beispielsweise ausdenken, dass es aus irgendeinem Business-Grund eine Liste von Produkten gibt, bei der jedes Produkt einen Preis hat, und es gibt einen Business-Grund dafür, dass man den Gesamtpreis dieser Produktliste wissen will.

Also ist  gesamt = produkte.gesamtpreis(); ein legitimer Ansatz auf hohem Abstraktionsgrad, ohne dass man konkret die Berechnungsvorschrift bestimmen muss - aber es wird vermutlich irgendwas mit Addition und Multiplikation sein.

Solange man nicht "die gesamte Welt" in seiner Produktliste hat und deren Preis bestimmen will, sondern es sich um realististe Warenkörbe in Shops handelt, dürfte der theoretisch erzielbare Parallelisierungsvorteil von Map-Reduce gegenüber iterativen Ansätzen nicht ins Gewicht fallen.

Ich finde es schlicht expressiver zu wissen, um welche mathematische Struktur es sich handelt.

Wenn man mit mathematischen Strukturen operiert, ist das sicherlich schlau.

Ein PHP-Array kann alles sein, ein Dictonary, eine Menge, ein Tupel, ein Stapel eine Schlange. Es erklärt sich mir nicht von selbst, welche Methoden überhaupt Sinn darauf machen.

Man wird sicherlich Arrays eher intern innerhalb von Objekten verwenden, um irgendein konkretes der obigen Konzepte abzubilden, und sie nicht nach außen anbieten. Auf der anderen Seite spricht aus meiner Sicht nichts dagegen, Arrays genau dann einzusetzen, wenn "mehr als eins" in einer Datenstruktur vorkommt - auch öffentlich erreichbar.

Noch schlimmer, wenn dann nicht mal die expressiven Methoden wie Map/Reduce benutzt werden, sondern ein Dschungel von Schleifen mir entgegenspringt. Bei einem map-Aufruf weiß ich, dass da wieder ein Array bei raus kommt, mit genau der gleichen Anzahl an Elementen, bei einem reduce weiß ich, dass da irgendetwas aggregiert wird. Das ist eine enorme Lese-Hilfe.

Du kannst natürlich schlechten, weil komplexen, Code als Negativbeispiel heranziehen, um gegen PHP-Arrays zu argumentieren. Ich stelle die Frage, ob man nicht genauso in einer Schlingpflanzenwelt von Closures und Callbacks zugrundegehen kann.

- Sven Rautenberg