Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^4: Pointers and References

by LanX (Cardinal)
on Nov 23, 2020 at 21:16 UTC ( #11124080=note: print w/replies, xml ) Need Help??


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

> 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; }

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

Replies are listed 'Best First'.
Re^5: Pointers and References
by GrandFather (Saint) on Nov 23, 2020 at 21:56 UTC

    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>; };

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11124080]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2021-06-13 12:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What does the "s" stand for in "perls"? (Whence perls)












    Results (55 votes). Check out past polls.

    Notices?