On Wed, Jul 16, 2008 at 10:54 PM, James Keenan via RT <[EMAIL PROTECTED]> wrote: > This module is written in Perl 5 and is called in a program written in > Perl 5. In the work I've done in this project, I've taken the approach > to return values which I think is more Perlish, namely, if a subroutine > completes and does what you wanted it to, it should return a true value. > A bare return returns an undef, which in Perl is false. False values > (whether empty string, empty list, 0 or undef) should indicate some > unsatisfactory completion of the subroutine. > > Having these subs end in a bare return to me connotes an unsatisfactory > outcome of some sort. That's why I did not have them end in bare > returns, and it's why I object to the changes that were made yesterday.
Not every function has a true/false return value. These methods that were refactored from the original script are only invoked once, and are just there to encapsulate code. They are not expected to return a true -or- false value. The one place they are invoked outside of the test suite treats them as a void return value and doesn't save the return value, let alone have a conditional based on it. Since there's no 'void' return in perl, undef is about as close as you can get. "I'm done, and I didn't die." That said, we can agree to disagree on that point for now, and leave the tests unchanged for the moment... ... because we can change the bare 'return;'s to 'return 1;' for now. That avoids the implicit return value that we were unintentionally getting, and will get us one step closer to passing the perlcritic policy [Subroutines::RequireFinalReturn]. > Thank you very much. > > kid51 > -- Will "Coke" Coleda
