nicht angemeldet
Das direke verändern ist in unzähligen Funktionen enthalten.
chomp() mal nur als Beispiel.
Tja, was soll man sagen, es ist ein Designfehler, dass die Funktion nicht das modifizierte Argument zurückliefert. Das zeigt sich sehr deutlich beim Verketten. Beispielcode (mit autoboxing):
[<DATA>]
->grep(sub {$_[0] !~ /\A (?: [#] | \s* \z )/msx}) # skip empty lines, comments
->map(sub {chomp $_[0]; return $_[0];}) # ← häääääääääässlich
->join(q{ })
->say
Glücklicherweise gibt es chomped.
Mir ist bewusst, dass dieser Designfehler sich häufig bei dünn umhüllten C-Funktionen bemerkbar macht.
[der geringere Verbrauch von] Speicher [ist ein Vorteil, weil Datenstrukturen nicht in der Gesamtheit kopiert werden]
Zugestanden. Mir ist das entfallen, weil ich nicht auf den Speicherverbrauch schaue, wenn ich mit Perl programmiere, denn das ist Sparsamkeit am falschen Ende und wie jede vorzeitige Optimierung ein größes Übel. Im Notfall lagere ich die kritischen Teile an Inline::C ö.ä. aus.
Aber einen Nachteil hast du nicht aufgezählt: [Modification of a read-only value attempted]
Moment mal, das ist kein Merkmal, das durch Referenzen, sondern Aliasing entsteht!
sub somefunc {
$_[0] = 'newvalue'; # funktioniert genauso schlecht.
}
somefunc('literal');
Wie bereits im letzten Beitrag angedeutet, soll man besser immer Kopien von @_ erzeugen statt Aliase.
Die Übergabe von Hashes oder Hashreferenzen erachte ich als auch bei prozeduraler Programmierung als Tugend, nicht nur in OOP.
Volle Zustimmung! Die Empfehlung lautet, Umstieg auf hashbasierte Parameter lohnt sich ab 3 Argumenten. Ich halte sie für falsch. Aus Erfahrung finde ich, man fährt *immer* mit hashbasierten Parametern am besten, auch wenn's nur einer ist. Es bringt Flexibilität für den Benutzer und Bequemlichkeit für den Programmierer von Anfang an.
Struppi