http://www.perlmonks.org?node_id=481584


in reply to Re: Perl Best Practices for naming variables
in thread Perl Best Practices for naming variables

# before Damian's book I'd have used EOREPLY my $reply_to_chester = <<'END_REPLY_TO_CHESTER';

Exactly right, that's what Damian recommends. There's obviously someone besides him who's made it work.

I suppose I've just solved the problem he's looking to address by never using identical identifiers for different purposes. What's the advantage to me for adding those extra four characters? Now I can use %option, @option, $option, and &option in the same scope and, uh, not get them mixed up? ;) On the flip side, what's the penalty for typing$items[1] when you meant $items->[1]? No more than a missing semi-colon, or other simple syntax error. Unless your program takes a long time to compile, no big deal: run, tweak, run, tweak...

I might not find this constraint so onerous if I hadn't produced a lot of code that goes up to 78 characters.

... (time passes while Marvin peruses book) ...

It looks like the answer is, for Perl 5.8.1 onwards, the Data::Alias module. The main situation where I'd need _ref is when pulling elements out of a large and complex object for manipulation in a method. Here's what I've been doing:

sub do_stuff { my $self = shift; my $items = $self->{items}; # Bear with me and assume I'll need $items again... for my $item (@$items) { # etc...
With the Data::Alias module, I can do this instead:
sub do_stuff { my $self = shift; alias my @items = @{ $self->{items} }; for my $item (@items) { # etc...

That's probably faster. It's sure cleaner. I like. And as a bonus, now when I use _ref, it will imply something useful -- like, "this is a giant array and I want to pass it by reference".

Tasty spinach, yo,

--
Marvin Humphrey
Rectangular Research
http://www.rectangular.com

END_REPLY_TO_CHESTER