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

[Zaxo]

That reminds me of a question I like to use for teaching intermediate-level perlers:

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

I think it makes a good interview question, too.

I don't think it is really the same reason at all. The reference/dereference cycle in your example is real, but insignificant, while the & sigil is usually optional but sometimes affects perl parsing and compilation. Ovid and tirwhan covered the traps nicely.

[Your Mother]

I'll bite. The second makes a copy of the array, the first doesn't. Right...? I hope. Or I've embarrassed myself terribly.

[Zaxo]

Right.

[Anonymous Monk]

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? :-(

[Zaxo]

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]};

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

[demerphq]

@{[...]} 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.

[jdporter]

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".)

[Anonymous Monk]

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! :-)

[jdporter]

@{[@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).

[Anonymous Monk]

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. :-) )