Will Coleda schrieb:
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].
Hi,
sorry for not running 'make buildtool-tests'.
The only reason for adding the empty returns, was that the
implementation was not in accord with function documentation.
In the POD for the changed functions there was:
Return Value: None.
I think the interface of a function should reflect it's intent. If only
internal state is modified,
I'm happy with returning undef or the empty list. On the other hand, I
wouldn't expect that a function returns 1,
only because the code ran successfully.
So I would be in favour of changing the tests.
But as I have no strong feelings about that, a return 1; would be fine
as well.
Regards,
Bernhard
