http://qs321.pair.com?node_id=11124213


in reply to Re^5: Pointers and References
in thread Pointers and References

Your use of do is obviously not wrong. I tend to reserve its use for when I have things I want to pass back out of it. As an example that I use sometimes when I'm in quick and dirty mode:

my $content = do { open my $fh, '<', $file or die "Couldn't open $file: $!\n"; local $/ = undef; <$fh>; };

Now I don't have to worry about $fh leaking to broader scope, local evaporates at the end of the do, and the contents of the file get returned. It's really just a convenience so I don't have to keep as much state in my head. I could also have done it like this:

my $content; { open my $fh, '<', $file or die "Couldn't open $file: $!\n"; local $/ = undef; $content = <$fh>; }

But I prefer using the naked block when I don't need to return something out of it. Another alternative that I occasionally find useful because it lets me make more explicit the passing of information into the construct is the immediate-use lambda expression:

my $content = sub { my $file = shift; open my $fh, '<', $file or die "Couldn't open $file: $!\n"; local $/ = undef; return <$fh>; }->($file);

If do{...} weren't so convenient I think I'd use the throwaway sub a lot more, as a means of limiting scope, and making parameter passing more obvious.

If I use naked blocks to reduce scope it's usually in cases where I don't need to return something. Example:

ok 1; { my $mock = Test::MockModule->new('Foo'); $mock->redefine(bar => sub {...}); is baz(10), 42, 'baz gave correct answer to the universe with bar +mocked.' } ok 3;

So here there's no intention of returning anything, we just want to constrain our mock to the narrowest scope practical so that we don't forget it's in place and spend two hours trying to figure out why some part of the test 80 lines below is failing in a mysterious way.

Sorry for digressing from the interesting thread's topic of references.


Dave