in reply to Re^2: What's so bad about &function(...)?
in thread What's so bad about &function(...)?

What is the difference between @{\@foo} and @{@foo}?

Um... they're both the wrong way to write @foo, but the second one's more inefficient, but caring excessively about efficiency of bad code that you should refactor anyway is a premature optimization, so ... umm... it's a trick question, with the answer of "There's no difference; you'ld never use either one in production code?"

Do I win? :-) Or did I miss something subtle? :-(

  • Comment on Re^3: What's so bad about &function(...)?

Replies are listed 'Best First'.
Re^4: What's so bad about &function(...)?
by Zaxo (Archbishop) on Dec 08, 2005 at 08:15 UTC

    You're half right, but you did miss something that jdporter missed, too.

    @{\@foo} is, as far as I know, a truly useless elaboration of @foo.

    The anonymous copy provided by @{[@foo]} is sometimes useful when you want to preserve @foo's contents. Example: 

    my @mutant_foo = map { mutator($_) } @{[@foo]};

    [download]
    It helps with for loops, too. That kind of situation comes up surprisingly often and the copy is an effective and unobtrusive solution.

    After Compline,
    Zaxo

[reply]
[d/l]
[select]

      @{[...]} also has the interesting side effect that it lets you interpolate a list inside of a quoted string. Which can be useful in some circumstances, like inside of a here doc. This actually applies to ${\(expression)} but the latter is a little less useful IMO.

      ---
      $world=~s/war/peace/g

[reply]
[d/l]

      I didn't miss anything. You seem to have missed my entire point, which was that the ampersand on a sub call is as useless an elaboration as the above array thing.

      (Of course, it's not really entirely as useless; it's only useless if you avoid coding in a way that exploits the ampersand's wierdness. In general, I avoid such coding, and claim it is a "best practice".)

      We're building the house of the future together.
[reply]
      Hmmm... are there other benefits?

      I never use mutator functions, nor the "alter in place" bindings of for loops. I also don't like to interpolate non-constant expressions into constant strings, like here docs or string interpolations...

      If I really need a copy of @foo, I'll label the copy with a proper variable name, do a normal assignment, and be done with it. No trickyness required! :-)

[reply]
Re^4: What's so bad about &function(...)?
by jdporter (Paladin) on Dec 07, 2005 at 22:50 UTC

    @{[@foo]} is really wrong, for the obvious reason that it copies the contents of @foo into a new (anonymous) array, so that, for example, splice( @{[@foo]}, 0, 5 ) does not modify @foo.

    But why is @{\@foo} wrong? Whatever the answer is, the same could be said of &foo() (aside from the extremely tiny overhead of taking and dereffing a ref).

    We're building the house of the future together.
[reply]
[d/l]
[select]
      But why is @{\@foo} wrong? Whatever the answer is, the same could be said of &foo() (aside from the extremely tiny overhead of taking and dereffing a ref). It's only wrong in the sense that:

       $great_answer=(((1+1)**(1+1+1))-1)*(1+1+1)*(1+1);

      is "wrong"; it's too complicated, and "should" read:
       $great_answer=42;

      (Alternatively, it's overly complicated for some good reason which was left undocumented, which is IMHO more wrong. :-) )

[reply]
[d/l]
[select]

In Section Meditations