Mailinglisten-Archive |
Alexander Meurer wrote: > > Hallo Enrico, hallo alexander, <snip> > Der einzige, der entscheiden sollte, ob ein Parameter als Referenz > übergeben wird, ist der Entwickler der Function - nicht der, der sie > benutzt! > > Wenn ich eine Function schreibe und mir vorstellen kann, daß dort > größere Datenmengen übergeben werden, so richte *ich* die Referenz ein. > > Außerdem kann es nicht Teil meines Konzeptes sein, die Variable zu > verändern, wenn ich gar nicht sicherstellen kann, daß der Benutzer > meiner Function den Parameter auch als Referenz übergibt! das haengt ganz vom verwendetem paradigmum ab. bei strikten sprachen, wie java oder oberon ist das sinnvoll so zu argumentieren. da liegt dem ganzen auch das ADT- bzw. klassen-modell zu grunde, welches ausdruecklich eine starke kapselung vorsieht. fuer viele anwendungen ist das sehr sinnvoll, weil es fehlerquellen vermeidet, den code stabiler und uebesichtlicher macht. allerdings gibt es auf der anderen seite weniger strikte sprachen, wie es meist bei script-sprachen der fall ist. das php zu den weniger strikten sprachen gehoert, ist offentsichtlich, beispielsweise am dynamischen namespace, sukzessiver compilierung (die es z.b. ermoeglicht zu laufzeit zu entscheiden, welche files included werden oder welche funktionen zu definieren sind). das ganze sind voellig verschiedene welten, so wie auch relationale- (SQL, prolog), funktionale- (haskell) oder listen-sprachen (lisp) voellig verschiedene welten (paradigmen) sind. ich halte es fuer wenig sinnvoll, sprachen wie PHP strikte paradigmen aufdruecken zu wollen. wenn du die sache konsequent weiterziehst, muesstest du dann naemlich auch die namens-basierte referenzierung ($$varname) oder ueberhaupt saemtliche dyn namespaces abschaffen, womit du dann irgentwann bei java oder der gaertnersprache landest ... (btw waere es sicher sinnvoll, auch andere sprachen parallel zu PHP in die zend-engine zu integrieren ...) freilich muss man bei unstrikten sprachen besonders darauf achten, dass man schnittstellen robust gestaltet und gut dokumentiert, jedoch hat man gegenueber den strikten den imensen vorteil, dass man fuer viele aufgaben (z.b. textprocessing im weitesten sinne) sehr schnell sehr komplexe systeme entwickeln kann. es ist halt so, dass unstrikte sprachen dem entwickler eine hoehere verantwortung fuer sein tun auferlegen, als sehr strikte. ~-n -- Enrico Weigelt == meTUX IT services software development, IT service, internet security solutions www: http://www.metux.de/ phone: +49 36207 519931 email: contact_(at)_metux.de cellphone: +49 174 7066481
php::bar PHP Wiki - Listenarchive