nicht angemeldet
Hi!
Nur dass man theoretisch Interfaces im Allgemeinen auch implementieren kann,
Na ja, was ist jetzt die Bedeutung von 'theoretisch' und 'im Allgemeinen' in diesem Satz?
'im Allgemeinen' ist da überflüssig.
Du kannst ohnehin als PHP-Anwender nichts derartiges nachbauen, was die Syntax für den Zugriff auf Daten beeinflusst, das ist nun mal 'built-in'. Dass sowas über Interfaces realisiert ist, finde ich auch reichlich beknackt. Wenn Du das sagen wolltest, dann bin ich voll auf Deiner Seite.
Dass dafür Interfaces verwendet wurden, finde ich schon in Ordnung. Wie sonst sollte man einen anwenderdefinierbaren Iterator-Meachanismus konzipieren? Das machen andere Systeme auch nicht wesentlich anders. Es gibt was definiertes, das man implementieren muss und dann iteriert es. Nur die Sonderlocke bei Traversable ist das, worüber ich mich amüsiere.
Es ändert aber nichts dran, dass es so ist: wenn Du die Iterierbarkeit eines Objektes prüfen willst, dann ist 'Traversable' zu prüfen, nichts anderes.
Ja, dass es Traversable extra zu diesem Zweck gibt, hab ich ja gestern schon durch deine Antwort mitbekommen. Das "nichts anderes" stimmt allerdings nicht ganz, denn Iterator und IteratorAggregate kann man auch prüfen, weil das die beiden einzigen Nachfahren von Traversable sind, auf deren Mitglieder letzlich die Funktionalität basiert und weitere nicht (durch Anwenderhand) entstehen können. Aus heutiger Sicht ist also beides vom Ergebnis gleichwertig. Dass später die PHP-SPL-Entwickler in Zukunft weitere direkte Nachfahren von Traversable erstellen, halte ich für eher unwahrscheinlich, denn mit einem Iterator und einem Iterator-Lieferer sollten sich da die Möglichkeiten schon erschöpft haben.
Lo!