Re^3: Pointers and References

Anonymous Monk is quite right. The do block is there to wrap up a "main". I don't usually bother, but in this case a previous iteration of the sub had variables with the same name as were in the main block of code so I used the do block to limit the scope of those variables.

As a general thing avoiding global variables is good. In larger scripts I write a formal sub main to ensure the only global variables are deliberate and explicit. So the do block is a light weight version of that practice that remained somewhat beyond its use by date, but a useful discussion point as it turns out.

[LanX]

> I used the do block to limit the scope of those variables.

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

{
    my $limited_in_scope;
}

[GrandFather]

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.

[davido]

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.

[Bod]

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

[GrandFather]

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.

[LanX]

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

[jcb]

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.