Array in Unterprogramm erstellt, in zweitem weiterverarbeitet

[Benny]

Hallo,
in einer erten Routine lese ich externe Daten in ein array ein,
in einer späteren möchte ich dieses array verarbeiten.
Wie mache ich dies sinnvollerweise, um die Global-Definition zu vermeiden

Bisheriger Ansatz:

  
<?php  
perform arrayErstellen()  
  
perform arrayAuswerten()  
...  
  
function arrayErstellen() {  
  global $myarray;  
...  
}  
  
function arrayAuswerten() {  
  global $myarray;  
...  
}  
  

Soll ich das array (leer) in der Hauptroutine definieren und dann jeweils als Parameter übergeben?
Wird dabei das komplette array kopiert und an die Subroutinen übergeben oder nur der Verweis darauf, d.h. habe ich nach Rückkehr aus dem Unterprogramm das Original-Array tatsächlich geändert?
Schönen Abend
wünscht Benny

[Tom]

Hello,

in einer erten Routine lese ich externe Daten in ein array ein,
in einer späteren möchte ich dieses array verarbeiten.
Wie mache ich dies sinnvollerweise, um die Global-Definition zu vermeiden

Mit einer sinnvollen Programmstruktur und dazu passender Datenhaltung.

Bisheriger Ansatz:

<?php

$_meinArray = arrayErstellen(## parameter ##);

$_mein_ausgewertetes_Array = arrayAuswerten($_meinArray);

  
  
  
Liebe Grüße aus dem schönen Oberharz  
  
  
Tom vom Berg  
![](http://selfhtml.bitworks.de/Virencheck.gif)  
  

-- 
 ☻\_  
/▌  
/ \ Nur selber lernen macht schlau  
<http://bergpost.annerschbarrich.de>

[Benny]

<?php

$_meinArray = arrayErstellen(## parameter ##);

$_mein_ausgewertetes_Array = arrayAuswerten($_meinArray);

>   
>   

Erst einmal herzlichen Dank.  
Jetzt habe ich aber dadurch ein weiteres Problem.  
Ich möchte in der obigen Routine "arrayErstellen" noch einen weiteren Wert zurückgeben. Natürlich könnte ich diesen in das array mit aufnehmen: Der wäre aber überflüssig im der zweiten Routine "arrayAuswerten".  
Naheliegend für einen Fast-Laien wäre ja:  
~~~php
  
<?php  
($rc, $_meinArray) = arrayErstellen(## parameter ##);  
  
....  
function arrayErstellen(## parameter ##) {  
  
...  
return ($rc, $_meinArray);  
}  

Aber leider sieht die Realität anders aus!
Könnt Ihr mir da noch einmal einen Tipp geben.
Danke Benny

[Tom]

Hello,

Jetzt habe ich aber dadurch ein weiteres Problem.
Ich möchte in der obigen Routine "arrayErstellen" noch einen weiteren Wert zurückgeben. Natürlich könnte ich diesen in das array mit aufnehmen: Der wäre aber überflüssig im der zweiten Routine "arrayAuswerten".

Dann gibt es den nächsten Denkschritt:

Anstelle einer rassereinen Funktion kannst Du auch eine mit Übergabeparametern bauen, die in Wirklichkeit Referenzen sind.

http://de2.php.net/manual/en/language.references.php

Als Funktionsergebnis nimmst Du dann den Wert, der Dir über Erfolg oder Misserfolg der Ausführung Antwort gibt und in den Referenzparetern (also deren Speicherbereiche) steht dann bei Erfolg das Ergebnis.

<?php

$_meinArray = array();
   $ok_meinArray = arrayErstellen(&$_meinArray, ## parameter ## );

$__mein_ausgewertetes_Array = array();
   $ok_mein_ausgewertetes_Array = arrayAuswerten(&$_mein_ausgewertetes_Array,$_meinArray);

nachfolgend Erfolgskontrolle für die Entwicklung

echo "<pre>\r\n";
   echo htmlspecialchars(print_r($_meinArray,1));
   echo htmlspecialchars(print_r($_ausgewertetes_Array,1));
   echo "/<pre>\r\n";

?>

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

Anstelle einer rassereinen Funktion kannst Du auch eine mit Übergabeparametern bauen, die in Wirklichkeit Referenzen sind.

Sowas möchte man aber lieber vermeiden. Es macht den Code unübersichtlich.

- Sven Rautenberg

[Tom]

Hello,

Anstelle einer rassereinen Funktion kannst Du auch eine mit Übergabeparametern bauen, die in Wirklichkeit Referenzen sind.

Sowas möchte man aber lieber vermeiden. Es macht den Code unübersichtlich.

Das ist mMn nicht wirklich unübersichtlich, aber in der Handhabung wird es umständlich. Man muss eben immer "vorbereiten", durchführen, prüfen, "nachbereiten". Die Daten liegen eben immer im Scope des ümhüllenden Programmteils (auf dem Heap) und müssen ggf. separat wieder entsorgt werden, wenn sie nicht mehr benötigt werden. Anders bei reinrassigen Funktionen. Da liegen die Antworten auf dem Stack und werden automatisch wieder entsorgt.

Ok, bei PHP kann das schon wieder etwas anders gehandhabt werden. Ist ja auch eine Interpreter-Sprache...

Aber als nächsten Entwicklungsschritt hat man ja deshlab die OOP ersonnen, die ich dennoch für Interpretersparachen als überskaliert betrachte. Aber das weißt Du ja. Aber die sorgt dann dafür, dass alle zum Objekt gehörenden Daten wieder verschwinden, wenn das Objekt aufgelöst wird.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Aber als nächsten Entwicklungsschritt hat man ja deshlab die OOP ersonnen, die ich dennoch für Interpretersparachen als überskaliert betrachte.

Es verlangt ja keiner, das ganze Projekt auf OOP mit allem Tod und Teufel (lies: sämtliche gängigen Entwurfsmuster) aufzusetzen. Ein kleines klassenloses Objekt[*] um die Antwort einzupacken reicht auch schon, genauso wie man in einem ansonsten prozeduralem oder auch Geradeaus-Code von einer SQL-Abfrage sich die Ergebnisse mit mysql_fetch_object() als Objekt abholen kann.

[*] Klassenlos gibt es eigentlich nicht, das macht PHP zu einer stdClass-Instanz.

dedlfix.

[Benny]

Hello,

Anstelle einer rassereinen Funktion kannst Du auch eine mit Übergabeparametern bauen, die in Wirklichkeit Referenzen sind.

Sowas möchte man aber lieber vermeiden. Es macht den Code unübersichtlich.

Das ist mMn nicht wirklich unübersichtlich, aber in der Handhabung wird es umständlich....

Obwohl ich noch nicht sehr weit in PHP drin bin,
finde ich die Lösung sehr einfach und übersichtlich - hat auch sofort funktioniert.
In einem kleinen Projekt kommt es wohl nicht so sehr darauf an, ob etwas automatisch gelöscht wird oder nicht.

Jedenfalls allen ein Dankeschön!

[dedlfix]

Tach!

Anstelle einer rassereinen Funktion kannst Du auch eine mit Übergabeparametern bauen, die in Wirklichkeit Referenzen sind.
Sowas möchte man aber lieber vermeiden. Es macht den Code unübersichtlich.
Das ist mMn nicht wirklich unübersichtlich, aber in der Handhabung wird es umständlich....
Obwohl ich noch nicht sehr weit in PHP drin bin,
finde ich die Lösung sehr einfach und übersichtlich - hat auch sofort funktioniert.

Gegen die Übersichtlichkeit spricht, dass entgegen dem normalen Verhalten einer Funktion das Ergebnis nicht "unten" sondern "oben" rauskommt. Man muss bei dieser Funktion immer im Hinterkopf behalten, dass der/die Eingabeparameter hinterher einen anderen Inhalt hat/haben.

dedlfix.

[Tom]

Hello,

Gegen die Übersichtlichkeit spricht, dass entgegen dem normalen Verhalten einer Funktion das Ergebnis nicht "unten" sondern "oben" rauskommt. Man muss bei dieser Funktion immer im Hinterkopf behalten, dass der/die Eingabeparameter hinterher einen anderen Inhalt hat/haben.

Daran erinnert einen ja ein "Merkzeichen": &.

Du bist doch sonst nicht gegen kompakte Schreibweise, wieso also hier?
Mister Explizitschreibweise wäre ich dann doch eher ;-)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Gegen die Übersichtlichkeit spricht, dass entgegen dem normalen Verhalten einer Funktion das Ergebnis nicht "unten" sondern "oben" rauskommt. Man muss bei dieser Funktion immer im Hinterkopf behalten, dass der/die Eingabeparameter hinterher einen anderen Inhalt hat/haben.

Daran erinnert einen ja ein "Merkzeichen": &.

Nur im Funktionskopf, aber nicht beim Aufruf. Wenn du da trotzdem zur Verdeutlichung ein & notierst, gibt es eine Deprecated-Meldung.

Du bist doch sonst nicht gegen kompakte Schreibweise, wieso also hier?

Kompakt und effizient ja, aber lesbar muss es bleiben.

dedlfix.

[Tom]

Hello,

Daran erinnert einen ja ein "Merkzeichen": &.

Nur im Funktionskopf, aber nicht beim Aufruf. Wenn du da trotzdem zur Verdeutlichung ein & notierst, gibt es eine Deprecated-Meldung.

Du bist doch sonst nicht gegen kompakte Schreibweise, wieso also hier?

Kompakt und effizient ja, aber lesbar muss es bleiben.

Stimmt. Ist mir auch klar, worauf Du hinauswillst. Ich wollte ich jetz nur mal ein bisschen rauslocken ;-)

Das Verhalten der Funktion oder in abgewandelter Form auch der Methode sollte man daher ganz pingelig genau beschreiben. Das ist mMn ja gerade bei der OOP die Krux, dass man nicht auf Anhieb sehen kann, welchen Einfluss die Methoden einer Klasse auf diverse Eigenschaften der Klasse nehmen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Das Verhalten der Funktion oder in abgewandelter Form auch der Methode sollte man daher ganz pingelig genau beschreiben. Das ist mMn ja gerade bei der OOP die Krux, dass man nicht auf Anhieb sehen kann, welchen Einfluss die Methoden einer Klasse auf diverse Eigenschaften der Klasse nehmen.

Damit wären wir beim Theoretisch-Philosophischen angekommen. Da wäre zunächst mal die ganz einfache Frage, ob es überhaupt außerhalb der Klasse von Interesse ist, was eine bestimmte Eigenschaft für einen Wert hat und was mit ihm geschieht. Private Eigenschaften sind bei der Betrachtungsweise von außen ohne Belang, protected markierte ebenso, die sind nur bei Vererbung wichtig. Bleiben die public-Eigenschaften. Und wenn dabei ein schlecht zu durchschauendes Verhalten in die Klase programmiert wurde, kann die OOP nichts dafür.

Aber dein Argument ist nur ein scheinbares OOP-Argument. Man kann es auch auf die herkömmliche Programmierung anwenden. Funktionen können genauso undurchsichtig programmiert werden.

dedlfix.

[Tom]

Hello,

Wie jetzt, Nicht mehr "Hi ... Lo"?
Oder ist das jetzt auch ein Fake-Posting?

Das Verhalten der Funktion oder in abgewandelter Form auch der Methode sollte man daher ganz pingelig genau beschreiben. Das ist mMn ja gerade bei der OOP die Krux, dass man nicht auf Anhieb sehen kann, welchen Einfluss die Methoden einer Klasse auf diverse Eigenschaften der Klasse nehmen.

Damit wären wir beim Theoretisch-Philosophischen angekommen. Da wäre zunächst mal die ganz einfache Frage, ob es überhaupt außerhalb der Klasse von Interesse ist, was eine bestimmte Eigenschaft für einen Wert hat

vielleicht nicht, welchen Wert sie _hat_, aber doch zumindest, wodurch der _beeinflusst_ wird.

und was mit ihm geschieht. Private Eigenschaften sind bei der Betrachtungsweise von außen ohne Belang,

Wer sagt das? Wenn die "privaten Eigenschaften" Einfluss auf das Verhalten ahben, sind die überhaupt nicth ohne Belang. Und wozu sollten sie sonst da sein, als Einfluss zu nehmen?

Für die übrigen gilt das Gleiche!

Aber dein Argument ist nur ein scheinbares OOP-Argument. Man kann es auch auf die herkömmliche Programmierung anwenden. Funktionen können genauso undurchsichtig programmiert werden.

Was drehst Du mir das Wort im Mund um? Bei der "herkömmlichen Programmierung" (also nicht bei Ajax, sondern bei Putzil *gg*) muss man Variablen, die nicht geändert werden sollen, ja nicht in Funktionen "hineinstecken", von denen man das Verhalten nicht kennt.

Bei der OOP sollte man tunlicht keine Methode aufrufen, deren Wirkung man nicht kennt.

Bei der "herkömmlichen Programmierung" sieht man wenigstens noch in der Funktionsdeklaration, welche Argumente Referenzen sind, sich also veräbdern können.

Bei der OOP weiß man (ohne die _Implementation_ zu kennen), überhaupt nicht, welche Eigenschaften es gibt, wie die sich bei Methodenverwendung verhalten und verändern können und welche Wirkung das dann haben kann.

OOP ist mMn noch undurchsichtiger, als die "herkömmliche Programmierung".

Wieso sollte man dann also keine Referenz-Argumente in einer Funktion verwenden?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Private Eigenschaften sind bei der Betrachtungsweise von außen ohne Belang,
Wer sagt das?

Das Black-Box-Prinzip.

Wenn die "privaten Eigenschaften" Einfluss auf das Verhalten ahben, sind die überhaupt nicth ohne Belang. Und wozu sollten sie sonst da sein, als Einfluss zu nehmen?

Für interne Speicherzwecke - ein Pointer eines Iterators zum Beispiel. Es interessiert mich als Verwender nicht, wie der Iterator sich merkt, welches Element als nächstes dran kommt, solange er mir das erwartete liefert.

Was von einer privaten Eigenschaft von außen sichtbar wird, wenn überhaupt, steht auf einem anderen Blatt. Falls der Wert allgemein interessant ist, wird es eine Zugriffsmethode geben. Und die kann auch noch je nach Implementierung Veränderungen vornehmen. Nur weil man mit PHP Einblick in den Quelltext der Klasse hat, heißt das noch lange nicht, dass man unbedingt deren Innenleben benötigt, um ihre Funktionsweise zu verstehen. Eine ausreichend ausführliche Dokumentation sollte genügen. Das funktioniert auch bei Dingen, die nur als Kompilat plus Dokumentation weitergegeben werden.

Wie gesagt, das ganze ist eine sehr theoretische Diskussion. In der Praxis wird man ohne Zweifel auf Sachen treffen, die von dieser idealisierten Vorstellung abweichen - warum auch immer - Fehler oder Absicht (oder beides gemixt).

Für die übrigen gilt das Gleiche!

Nö, öffentliche Eigenschaften sind deutlich stärker von Belang als private Dinge. Wenn öffentliche Eigenschaften sich undurchsichtigerweise verändern, ist das des Programmierers Schuld, nicht das der OOP.

Aber dein Argument ist nur ein scheinbares OOP-Argument. Man kann es auch auf die herkömmliche Programmierung anwenden. Funktionen können genauso undurchsichtig programmiert werden.
Was drehst Du mir das Wort im Mund um?

Vielleicht antworte ich einfach nur auf das, was ich verstanden habe und nicht was du sagen wolltest.

Bei der "herkömmlichen Programmierung" [...]  muss man Variablen, die nicht geändert werden sollen, ja nicht in Funktionen "hineinstecken", von denen man das Verhalten nicht kennt.

Wenn sie von der Funktion nicht verwendet werden, interessieren sie auch nicht bei der Betrachtungsweise eines bestimmten Verhaltens. Ich glaube, ich verstehe grad nicht, worauf du hinauswillst.

Bei der OOP sollte man tunlicht keine Methode aufrufen, deren Wirkung man nicht kennt.

Und? Was ist dabei anders als bei der Nicht-OOP?

Bei der "herkömmlichen Programmierung" sieht man wenigstens noch in der Funktionsdeklaration, welche Argumente Referenzen sind, sich also veräbdern können.

Nur wenn sie keine Nebenwirkungen (neudeutsch side effects) hat. Funktionen tun auch interne Dinge mit lokalen Variablen, die natürlich irgendwelches Verhalten beeinflussen. Warum sollte das der OOP nicht im Rahmen ihrer erweiterten Möglichkeiten zugestanden werden?

Bei der OOP weiß man (ohne die _Implementation_ zu kennen), überhaupt nicht, welche Eigenschaften es gibt, wie die sich bei Methodenverwendung verhalten und verändern können und welche Wirkung das dann haben kann.

Genau wie bei der Nicht-OOP.

OOP ist mMn noch undurchsichtiger, als die "herkömmliche Programmierung".

Du hattest auch schon mal gehaltvollere Argumente. Zur Abwechslung kannst du ja mal über die Möglichkeiten der OOP nachdenken und nicht immer nur Nachteile in ihr suchen.

Wieso sollte man dann also keine Referenz-Argumente in einer Funktion verwenden?

Frage zurück: Warum sollte man, wenn es vielleicht besser geht? Wenn man mehr vom großen Ziel des OPs kennen würde, käme man vielleicht auf eine Lösung, die komplett anders funktioniert, sich damit besser in die Landschaft integriert und keine "ausgefallenen" Mittel verwenden muss.

Es ist ja auch kein Dogma, in PHP gibt es beispielswiese mit den Array-Sortierfunktionen Anwendungsfälle. Da ist der Anwendungsfall ziemlich klar: Das übergebene Array wird gemäß dem Funktionsnamen sortiert. Natürlich hätte man auch eine Funktion schreiben könenn, die ein sortiertes Array zurückgibt. Vermutlich hat sich jemand überlegt, dass man doch eher nur ein sortiertes und keine zwei Arrays braucht.

dedlfix.

[Fred Furunkelstein 2011]

<?php
   $ok_meinArray = arrayErstellen(&$_meinArray, ## parameter ## );
?>

Tom, das ist ganz schrecklich. Da kommt man ja aus dem Kommentieren gar nicht mehr heraus - sonst weiß niemand warum, wieso oder gar weswegen in $_meinArray was gespeichert wird.

Wenn man das schlanker und übersichtlicher haben will kann man in arrayErstellen() gleich versuchen den Array zu erstellen und wenn das (oder ein vorheriger Schritt) schief geht wird eben nur ein Skalar mit dem WERT FALSE (oder was auch immer) zurück gegeben:

Beispiel:

/**  
 * Liefert entweder einen array oder eine additive Kombination folgender Fehlernummern:  
 *  1 Ein Fehler.  
 *  2 Ein anderer Fehler.  
 *  4 Diesen Fehler gab es noch nie.  
 * Liefert die Funktion 5, dann gab es "Ein Fehler" und den Fehler, den es noch nie gab (1+4).  
 */  
function array_erstellen()  
{  
  
    $ar=array();  
    $errNumber=0;  
    // tu dies  or $errNumber=$errNumber+1;  
    // tu das   or $errNumber=$errNumber+2;  
    // tu jenes or $errNumber=$errNumber+4;  
    // Ups! Ein Array! $ar! (Oder aber nicht...)  
    if (0 != )  
    {  
          return $errNumber;  
    }  
    return $ar;  
}  
  
  
$ar=arrayErstellen(## parameter ##);  
if (is_array($ar))  
{  
    // tu dies  
} else {  
    // mach jenes in Abhängigkeit der Fehlernummer  
}  
  

[Tom]

Hello,

Tom, das ist ganz schrecklich. Da kommt man ja aus dem Kommentieren gar nicht mehr heraus - sonst weiß niemand warum, wieso oder gar weswegen in $_meinArray was gespeichert wird.

Was ist daran schrecklich?

Wie würdest Du das denn machen, wenn Du auf jeden Fall einen Statuswert als Rückgabewert haben musst, und der zu bearbeitende Datenwert variant ist, also z.B. auch ein Skalar, NULL oder ein Objekt sein kann?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Fred Furunkelstein 2011]

Was ist daran schrecklich?

Das ich eine Variable, die ich verändere, nicht auf der linken Seite stehen habe.

Wie würdest Du das denn machen, wenn Du auf jeden Fall einen Statuswert als Rückgabewert haben musst, und der zu bearbeitende Datenwert variant ist, also z.B. auch ein Skalar, NULL oder ein Objekt sein kann?

Ist doch klar: einfach! Und zwar so einfach wie nur irgend möglich, aber immer mit der Veränderlichen auf der linken Seite.

1. Skalar:

function getMyData()  
{  
    ...  
    return array(value, status)  
}  
  
list ($ergebnis, $status) = getMyData();

2. Skalar, Array oder Hash

function getMyData()  
{  
    $values = array(....);  
    $status = 'Foo!';  
    return array($status, $values);  
}  
  
$arMyData = getMyData();  
$status=array_shift($arMyData);  

Würde ich in der Funktion ein Objekt bauen, dann würde ich kurzerhand die Eigenschaft "build_errors" mit vorsehen, zurück geben und auswerten. Das wäre es dann schon.

Fred

[Tom]

Hello R.,

Was ist daran schrecklich?

Das ich eine Variable, die ich verändere, nicht auf der linken Seite stehen habe.

Auf welcher Seite steht denn die Eigenschaft (von außen betrachtet), die Du mit der Methode

$c->set_color(#200);

ansprichst. Richtig! Die sieht Du gar nicht! Wie die Klasse das macht, interessiert nicht.

Das Zurückgeben eines "Arrays" ist aber auch nicht der Standard bei Programmiersprachen und schon gar nicht, eines unspezifizierten.

Interpretersprachen geben einem da eben Müglichkeiten, die man in Compilersprachen üblicherweise nicht hat.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Was ist daran schrecklich?
Das ich eine Variable, die ich verändere, nicht auf der linken Seite stehen habe.
Auf welcher Seite steht denn die Eigenschaft (von außen betrachtet), die Du mit der Methode
   $c->set_color(#200);
ansprichst. Richtig! Die sieht Du gar nicht! Wie die Klasse das macht, interessiert nicht.

Es geht im vorliegenden Fall um eine nicht zur Klasse gehörende Variable - genauer, eine Funktion ändert/erzeugt eine Variable. Da die gesamte Aufgabenstellung nicht bekannt ist, können wir keinen realistischen Vorschlag bringen, wie man diese mit der OOP lösen würde, also ob mit einem gut durchdachten Design überhaupt ein "außenliegendes" Ergebnis benötigt wird oder ob die Klase selbst das Array verwalten kann und selbiges gar nicht öffentlich wird.

Das Zurückgeben eines "Arrays" ist aber auch nicht der Standard bei Programmiersprachen und schon gar nicht, eines unspezifizierten.

In Compilersprachen auch objektorientierten hat man noch genügend Anwendungsfälle, bei denen ein unspezifiziertes Object zurückgegeben wird, das man sich erst noch typecasten muss. Die Fälle werden durch diverse Maßnahmen wie Generics weniger, aber sie sterben nicht aus. Die Rückgabe von Arrays ist auch keine Seltenheit. Du meinst sicherlich Arrays mit gemischtem Inhalt. Die wird man wohl eher vermeiden wollen und sich stattdessen für das Ergebnis eine Klasse mit den benötigten Eigenschaften erstellen. Oder aber man signalisiert unerwartete Status während der Verarbeitung mit Exceptions.

dedlfix.

[dedlfix]

Tach!

Naheliegend für einen Fast-Laien wäre ja:

($rc, $_meinArray) = arrayErstellen(## parameter ##);

....
function arrayErstellen(## parameter ##) {
...
return ($rc, $_meinArray);
}

> Aber leider sieht die Realität anders aus!  
  
Gerinfügig, ja. Deine Schreibweise sieht nach Tupeln aus, die zwar Python kennt, doch PHP nicht. Kann man aber nachbilden. Das Sprachkonstrukt [list()](http://php.net/manual/en/function.list.php) hilft dir, Array-Elemente in einzelne Variablen zu speichern. Das kannst du beim Empfang des Funktionsergebnisses anwenden. Dazu musst du die beiden Elemente in der Funktion jedoch als Array zurückgeben. Somit sind die Klammern schon richtig, aber sie müssen noch mit list und array ergänzt werden.  
  
  
dedlfix.

[Sven Rautenberg]

Moin!

Jetzt habe ich aber dadurch ein weiteres Problem.
Ich möchte in der obigen Routine "arrayErstellen" noch einen weiteren Wert zurückgeben. Natürlich könnte ich diesen in das array mit aufnehmen: Der wäre aber überflüssig im der zweiten Routine "arrayAuswerten".

Sicher? Das ist ein Indiz dafür, dass deine Funktion zuviel tut. Was genau tut sie denn eigentlich?

Objektorientiert könnte man die Show an dieser Stelle ja durchaus retten.

- Sven Rautenberg

[dedlfix]

Tach!

Soll ich das array (leer) in der Hauptroutine definieren und dann jeweils als Parameter übergeben?

So ist es sinnvoll, wenn man nicht mit globalen Variablen arbeiten will.

Wird dabei das komplette array kopiert und an die Subroutinen übergeben oder nur der Verweis darauf,

Sowohl als auch. Für dich als Anwender sieht das wie eine Kopie aus. Alles außer Objekten wird per Kopie übergeben. Intern aber übergibt PHP zunächst eine Referenz, das macht es bei allen Variablen, nicht nur bei Arrays. Du hast damit zwar zwei Variablennamen, einen außen und einen funktionslokal, aber sie zeigen beide auf denselben Variablencontainer (der Wert und Typ und noch etwas verwaltungstechnischen Kleinkram speichert). Erst wenn sich der Inhalt ändert, wird ein zweiter Variablencontainer erstellt und dem jeweiligen Variablennamen zugeordnet.

Derick Rethans hat das mal in References in PHP: An In-Depth Look beschrieben. Seinen Artikel findet man, wenn auch versteckt im PHP-Handbuch verlinkt unter debug_zval_dump().

d.h. habe ich nach Rückkehr aus dem Unterprogramm das Original-Array tatsächlich geändert?

Nein, nur bei Referenzen. Also explizit damit arbeiten oder Objekte verwenden.

dedlfix.