Verstanden. Du beschränkst sub also auf einen spezifischen Code-Block innerhalb _einer_ Aufgabenstellung. OK. Sobald Du (wie Du Deine Namensräume hierbei organisierst, hat damit IMHO erstmal nichts zu tun) _eine_ "sub" nun aber aus verscheindenen "Mains" z.B. "main1.pl, main2.pl" verwenden willst, sieht die Sache spätestens anders aus... Das muss kein "autarkes selbstverantwortliches Ding mit seinem eigenen EVA Prinzip, das irgendwo im Netz betrieben wird" sein, sondern kann schlicht etwas darstellen, was ich innerhalb wiederkehrender Aufgabenstellungen verwenden möchte, um meinen Code sauber zu organisieren.
Ok wir kommen uns näher.
Du musst nur unterscheiden, wer der Master und wer der Slave ist.
In einem traditionell gepflegten php Umfeld ist jede HTML Seite ein php Hauptscript. Alles andere ist shared. Ich bin mit dieser Architektur sehr ungemütlich.
Etwas anderes ist es, wenn du mehr von einer zentralisierten Behandlung ausgehst. Hier hast du einen Master und viele Slaves. Es kann aber auch sein dass du Clients hast, also solche die auch Slaves von anderen Mastern sind. Jetzt musst du aufpassen, welcher Master diesem Client am meisten seinen Willen aufzudrängen versucht. Ein SMTP Mailversand ist als Client OK, denn der Master ist von der Rückgabe eigentlich weitgehend unabhängig. Aber so etwas wie einen geteilten Formularmanager, der den Bedüfnissen beider Master gerecht werden soll, geht sehr schnell schief.
Perlish gesprochen: Wenn das Masterscript einem Modul einen Parameter Wert zur kontextspezifischen Behandlung übergibt, wobei verlangt wird, dass das Modul in keiner Weise die hergestellte Kanonizität des Feldwertes ändern darf, dann übergibt das Masterscript dem Modul eine Kopie der Variable.
Wenn das Masterscript einem Modul einen Wert übergibt um eine Kanonizität herzustellen, dann übergibt es eine Referenz.
mfg Beat
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische