http://qs321.pair.com?node_id=569144

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 ,= w +ould fit very elegantly into the perl arsenal of operators



Evan Carroll
www.EvanCarroll.com

Replies are listed 'Best First'.
Re: Should perl implement ,= or maybe overload .= (array context)
by theorbtwo (Prior) on Aug 23, 2006 at 17:41 UTC

    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
        We've debated adding ,= to Perl 6, but so far have decided it would too easy to confuse with the .= operator visually. I suppose we could add ,= just for completeness and then come back in six months and deprecate anyone who is using it. :-)

        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.

Re: Should perl implement ,= or maybe overload .= (array context)
by zshzn (Hermit) on Aug 24, 2006 at 05:19 UTC
    I find this idea very intriguing. ,= looks so perfect for arrays that it seems almost essential. That is to say, it is as if such a combination of two characters exists merely to fit this use. It feels so right, so devilishly Perlish.

    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.