SPUG: Interesting bug using 'map'
BenRifkah Bergsten-Buret
mail.spammagnet at gmail.com
Fri Apr 10 12:40:51 PDT 2009
On Fri, Apr 10, 2009 at 11:30 AM, Mark Mertel <mark.mertel at yahoo.com> wrote:
> instead of using map, you could use a hash slice:
> my ($fee, $fi, $fo) = @{ $fropper || $gropper }{ qw/fee fi fo/ };
>
Not exactly. I thought of this as well and it seems you might get a tiny
performance gain doing it this way since the existence of $fropper is only
evaluated once.
Looking more closely I realized that the OP is doing method calls
"$fropper->$_" instead of hash lookups "$fropper->{$_}". A slice in this
case would only work if you had these objects tied to a hash class that
overloaded FETCH with a method call. I imagine that would incur a
performance penalty.
The fact that these are method calls is the reason that Phil is running into
the scalar vs. list context issue. A hash look-up have this problem.
If I knew there were a ton of methods to be called I might do this:
my $opper = $fropper || $glopper;
my ($fee, $fi, $fo, ...) = map {scalar($opper->$_)} qw/fee fi fo .../;
Of course, if calling any of these methods on $glopper has the side effect
of changing the existence of $fropper then this won't give you the same
result as in Phil's example.
--
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/spug-list/attachments/20090410/a192fda2/attachment.html>
More information about the spug-list
mailing list