Re^3: What's so bad about &function(...)?
by Your Mother (Archbishop) on Dec 07, 2005 at 19:15 UTC
|
I'll bite. The second makes a copy of the array, the first doesn't. Right...? I hope. Or I've embarrassed myself terribly.
| [reply] |
|
|
| [reply] |
Re^3: What's so bad about &function(...)?
by Anonymous Monk on Dec 07, 2005 at 21:35 UTC
|
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? :-(
| [reply] |
|
|
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.
| [reply] [d/l] [select] |
|
|
| [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] |
|
|
@{[@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] |