maybe consider a "naked BLOCK" instead of do BLOCK to limit the scope.

{
    my $limited_in_scope;
}
[download]

Sure. For me naked blocks in C++ and similar languages are almost universally scope limiting blocks for process locking of various sorts. I tend to not use them in other contexts and that bleeds through to Perl. And again, for trivial code like this I wouldn't usually bother, but I was "belt and braces" checking the example code in an earlier iteration and forgot to remove the block.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

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>;
};
[download]

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>;
}
[download]

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);
[download]

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;
[download]

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

Where I want to explicitly show that a variable is deliberately global, I declare it with our.

I almost never use our. Usually when I say global I mean global to the file and I might prefix the variable name with a g. our tells you something is "global" where you declare the variable, but it doesn't tell you that where you use it. You tend to use a variable much more often than you declare it so the ugliness of a g prefix is an immediate and obvious reminder at the point of use that this is a global variable.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Your coding style is peculiar, probably C'ish? ;)

> our tells you something is "global" where you declare the variable, but it doesn't tell you that where you use it.

I have problems to follow. our $var creates a lexically scoped alias to a package variable $PKG::var whith PKG for the current __PACKAGE__ . If you are afraid to loose count "where you use it" just limit the scope, much the same way you do with private vars declared with my.

> of a g prefix is an immediate and obvious reminder at the point of use that this is a global variable.

Then maybe consider full qualification instead of a g_ prefix.

Using $PKG::var is IMHO much clearer, and $::var is a handy shortcut for $main::var

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

I use a simple convention: local variables have names in all_lowercase, global variables have names with an Initial_capital, and constants or quasi-constants have names that are ALL_UPPERCASE.