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