I was I was babbling in #perl on irc.freenode.net about the perl design decision to not overload '.=' to work differently when operating on an array (pushing.) I feel this should work 'as I expect it to', and there is no reason to make this operator useless when the lhs is an array, or array ref. However, my opinions aside, Rindolf made a suggestion that should be the subject of meditation and might fit even more with the Perl ideology. ",=". It should be noted that such an operator wouldn't cause breakage with 5.10 because of its status in 5.8 -- nonexistent. It would be looked upon like //=, as sexy syntactic sugar.
Transcript as follows:
12:03 < EvanCarroll> eval: @_=[qw/foo bar baz/]; @_ .= 'bleh'; @_; 12:03 < buubot> EvanCarroll: Error: Can't modify array dereference in concatenation (.) or string at eval line 1, at EOF 12:03 < EvanCarroll> didn't think so 12:03 < EvanCarroll> oh well back to pushing 12:03 < rindolf> EvanCarroll: maybe there should be a ,= 12:04 < rindolf> EvanCarroll: you can also try to overload an operator. 12:04 < EvanCarroll> rindolf: wow, thats actually a good idea. 12:04 < EvanCarroll> rindolf: I won't overload it for myself; but ,= would fit very elegantly into the perl arsenal of operators
Evan Carroll
www.EvanCarroll.com
To me, making .= do array concat seems rather off, for similar reasons to + not doing string concat. It's just not the right operator for the job. ,= is rather more interesting, but I don't really see a reason to introduce it; push @foo, @bar works just like you'd propose @foo ,= @bar to do.
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
I agree fully with the example on '+', and '.' operators and that's why I thought ,= was more consistent with perl philosophy; but favoring a function'al approach rather than an operator approach for arrays seems more consistent with PHP a la array_new. As a side note though the analogy doesn't hold entirely true, perl -e'print "4 foo"+"1"' will demonstrate a purpose for +'ing two strings.
I like '.=' more because it is clear what it should do in either context, and i don't really see a need for a ',='. Either operator would have a lower level of precedence too.
Evan Carroll
www.EvanCarroll.com
As for unifying with the .= operator, that wouldn't work at all in Perl 6 because we've taken over dot for method calls, and .= already indicates that you want to turn a non-mutating method call into a mutating method call. The append operator in Perl 6 is the ~=, but in Perl 6 the ~ character has very strong implications of stringification, and we wouldn't want to break that.
All that being said, it'd be trivial for you to add your own ,= operator to Perl 6, and that's probably where we should leave it.
However, issues arise. Firstly, as brought up above, it could be confused for .=, as I personally confused myself reading the post. Secondly, it is a bit much, a bit excessive even for Perl, to add an operator to do exactly what a function already does. Most crucially, and thirdly, Perl's operators are scalar operators. Perl is a scalar-based language. Deviation from that should be done only as an act of revolutionary policy, not as a whim for a delightful yet unnecessary feature.