Algorithmus optimieren

[Bademeister]

Allerdings - und ich habe meinen Denkfehler gefunden. Ich arbeite normalerweise nicht mehr mit nativen Arrays, sondern mit einer Collection Klasse, die in einem Framework ist, an dem ich arbeite. Da ist es so, dass über die Klasse selber iteriert wird und nicht über eine Kopie derer (durch das Implementieren von Iterator? kann man mit foreach drüber iterieren).

Ok, mit dem Iterator-Interface wäre es schwierig zu implementieren, dass über Kopien iteriert wird. Aber das Iterator-Interface ist m.E. für Implementierungen von Array-Objekten ohnehin unbrauchbar, denn es bringt noch ein anderes gefährliches Problem mit, über das ich mal gestolpert bin:
Wenn man in die Situation kommt, verschachtelte Iterationen machen zu wollen, weil man zum Beispiel über alle Paare von Werten iterieren will:

  
foreach ($myArray as $thisValue1) {  
    foreach $myArray as $thisValue2) {  
         ....  
  
    }  
}  

dann geht das i.a. mächtig schief. Grund - klar - die beiden Schleifen benutzen nicht nur dieselben Werte, sondern auch denselben (virtuellen) internen Zeiger. Das heißt, dass, wenn man nicht einige Verränkungen anstellt, die äußere Schleife nach dem ersten Durchlauf beendet ist, weil der interne Zeiger nach der ersten Abarbeitung der inneren Schleife am Ende des (virtuellen) Arrays steht.

Daher empfehle ich Dir im allgemeinen stark die Implementierung von IteratorAggregate statt Iterator, was dann für jede Schleife einen eigenen externen Iterator erzeugt, der sich mit den anderen nicht in die Quere kommt. Dann ist es i.a. auch wieder problemlos möglich, über eine Kopie der eigenen Daten zu iterieren, um Deinem Daten-Änder-Problem wieder aus dem Weg zu gehen.
Das Iterator-Interface eignet sich nur gut, wenn es sinnvoll ist, verschachtelte Iterationen konzeptionell zu verbieten (und ggf. mit einem Fehler zu würdigen), wie zum Beispiel für das iterative Auswerten von Ressourcen o.ä.

Darin ist jeweils nur diese eine Klasse definiert. Jetzt ist es so, dass manche Klassen im Framework Scope liegen und manche Klassen in Application Scope - und damit in anderen Verzeichnissen.
Bisher war es einfach, da es genau 4 Verzeichnisse gab, wo Klassen liegen konnten. Jetzt werde ich aber verschiedene Sachen einbauen, wo es notwendig ist, dass Klassen auch in Unterverzeichnissen dieser Verzeichnisse liegen (z.B. liegen die Klassen eines Plugins im Verzeichnis dieses Plugins und nicht im allgemeinen Plugin-Verzeichnis). Also brauche ich alle diese Pfade.

Verstehe ich immer noch nicht. Kannst Du der Klasse (d.h. Klassenname und ggf. Namespace) ansehen, in welchem Verzeichnis die Datei liegt? Und wenn nicht, was macht die __autoload()-Funktion dann?

Viele Grüße,
der Bademeister