Re: Warning about unused lexical variables

My (small) problem with this would be that the "unused" variable might still serve some purpose. Consider a compute_some_value() like one of these:

sub pay_attention {
   die 'void context' if ! defined wantarray;
   return rand;
}
sub side_effect {
   print "I am happy.\n";
   return;
}
sub wait_for_destruction {
   return OnDestroyDo->new( \&side_effect );
}
[download]

In case that last one is not clear, the idea is that it returns an object that will perform some action when it is destroyed.

Arguably a warning is still warranted in even these cases, but it might not be easy to tell when an assigned value is really superfluous.

Comment on Re: Warning about unused lexical variables Select or Download Code

Replies are listed 'Best First'.
Re^2: Warning about unused lexical variables by xdg (Monsignor) on Sep 04, 2007 at 20:52 UTC
the "unused" variable might still serve some purpose Another example would be "anonymous" scalar references. `my $scalar_ref = \(my $s);` [download] Or would taking a reference count as "using" it? -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply] [d/l]
Re^2: Warning about unused lexical variables by bart (Canon) on Sep 05, 2007 at 11:06 UTC
That's right. Check this article on perl.com on what this could be used for: Better Code Through Destruction.	[reply]
Re^2: Warning about unused lexical variables by papidave (Pilgrim) on Sep 07, 2007 at 22:08 UTC
Perhaps I'm too much of a C++ hacker, but I tend to use this capability heavily. Consider a Foo::Lock class which implements a lock on a Foo, where foo might be a file, database record, etc. Then, your methods inside Foo.pm can be made "safe" by code like: `sub do_something() { my $obj = shift @_; my $crit = new Foo::Lock( $obj ); $crit->lock(); # now do something in the critical section ... $obj->yada_yada(); return unless $obj->valid(); # now do some more stuff... $obj->yada_yada(); return( $result ); }` [download] In this case, we don't have to free the Lock explicitly, because its DESTROY method does that automagically. And we are never left with a hard-to-track deadlock defect because our app took a fatal somewhere, leaving the Foo accidentally locked. On the other hand, if $crit were cleaned up soonest, we couldn't depend on the critical section being held for as long as we need it.	[reply] [d/l]