in reply to Re^3: use constant for strings (unary plus)
in thread use constant for strings

Out of interest, why do you favour map +...., @.. over map{ ... } @..?


Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.

Replies are listed 'Best First'.
Re: Re: Re^3: use constant for strings (unary plus)
by diotalevi (Canon) on Apr 18, 2003 at 22:15 UTC

    Because the map +expr, syntax is great whe you have exactly one expression - I really dislike having a block around when it is so completely superfluous. The concepts conflict - applying an expression or applying a block. This allows the right idiom to be maintained. Its also concise which is a virtue.

    It also happens to be a bit cheaper since you don't get the overhead of a block.

Re^5: use constant for strings (unary plus)
by Aristotle (Chancellor) on Apr 19, 2003 at 00:33 UTC
    What he said.

    Makeshifts last the longest.

      Intriquing. The very best savings I could achieve using map $_, list over map{ $_ } list; was under 1%. And I thought I was the clown of micro-optimisations:)

      The number of chars is identical, and even comparing the dumps using perl -MO:Bblock... show only minimal differences.

      I tend to stick with the block form as it allows me to insert additional statements (like print;) into the block without having to change the syntax which I find especially useful when debugging pipelined maps, grep's and sorts--as used in the ST.

      Personally, I find it visually clearer too. TIMTOWTDI:) YMMV... etc. etc.


      Examine what is said, not who speaks.
      1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
      2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
      3) Any sufficiently advanced technology is indistinguishable from magic.
      Arthur C. Clarke.
        It's not really for the savings, as he already said, so much as for the conceptual purity. The only reason to use a block here is parsing rules. I can say something like
        @username = map scalar getpwuid($_), @uid;
        The only reason I can't say
        @year = map (localtime $_)[5], @timestamp; # "Not enough arguments for map at line XY"
        is parsing rules. Using a block just because this is parsed slighly differently than the first example basically feels like a kludge, like clutter. It's like saying
        print do { (localtime $timestamp)[5] };
        instead of
        print +(localtime $timestamp)[5];

        Makeshifts last the longest.