I see that we have started removing the bare return from
the codebase. This is a mistake.
I am not much a fan of arguments from authority, but I've
brought a couple.
If you look at the followers on the various pages for
ProhibitExplicitReturnUndef and Freenode's EmptyReturn
policies you find well-respected endorsers of PERU and
few for ER.
CERT presumably as a clue on this issue as regards security,
if not, our underlying protocols are suspect.
ProhibitExplicitReturnUndef is usually considered to be of
the highest severity level.
*----------
This is a case against allowing returns of explicit undef
supported by a EmptyReturn policies.
PREAMBLE / DWIMERY.
The normal initial view of dwimery is to not notice it.
Dwimery is the principle of least surprise in action. Dwimery
is great; we can get things done while ignorant.
But sooner or later, we run into problems. In the case under
discussion, we realize that the bare return is returning () and
undef. And when we find that our lists are missing the undefined
elements we meant to insert, we may decide the magic of the
bare return is bad.
But the bare return is not so magical. It is just one cog
of one gear in in the clockwork of Perl.
THE BARE RETURN IS NOT DOING WEIRD STUFF.
It just fits in.
When the builtin function caller
has nothing to say it behaves like a bare return.
The empty list ()
the undefined scalar undef
and
the empty routine sub mt {}
all evaluate to the empty list or scalar undef
depending on context.
The bare return is designed to let us follow a design feature
of the language succinctly; it allows us to replace a list,
scalar, array, or expression with a subroutine and not have to call
wantarray to emulate the boolean nature of the thing replaced.
You will be miserable until you learn the difference
between scalar and list context...
Programming Perl, Larry Wall, Tom Christiansen
& Randal L. Schwartz
TRUE ne FALSE or WHAT'S WRONG WITH sub { return undef }
It is true or false depending in which context we are.
And since this is about helping those who cannot easily
recognize Perl context, this just sets a different trap.
And teaches people to program in a way that fights the
design of the language.
when you write a subroutine that is "only ever going
to be used [in one context]"*
[footnote] *Yep. that's the sound of alarm bells
you're hearing.
Perl Best Practices, Damian Conway
SOLUTION
Context is a feature that permeates the language, it would
be good to learn how it works. There is no other complete
solution to the problem (other than using another language).
Perhaps these ideas will help:
Think of list context as the default. If we are providing
scalar context but are not sure, we can insert 'scalar' before
a subroutine call without harm. So if we want an explicit
undef, we can always force it with 'scalar'.
People come to Perl and often bring a conception that parentheses
make lists. This is not true. Context makes lists and in list
context the comma is just the list separator.
Regarding parentheses, the one exception is '()' is an empty list
and can be used to force list context: '$val = () = something();'
Be well.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
