Empty Hash Values
uri at stemsystems.com
Tue Apr 14 22:19:00 BST 2009
>>>>> "DC" == Dave Cross <dave at dave.org.uk> writes:
DC> Dave Hodgkinson wrote:
>> And fails PBP for exactly the confusion in previous mails. Plain
>> return is Just Wrong. Be explicit.
DC> PBP disagrees with you.
DC> 9.12. Returning Failure
DC> Use a bare return to return failure.
DC> Notice that each final return statement in the examples of the
DC> previous guideline used a return keyword with no argument, rather
DC> than a more-explicit return undef.
DC> Normally, relying on default behaviour is not best practice. But in
DC> the case of a return statement, relying on the default return value
DC> actually prevents a particularly nasty bug.
DC> The problem with returning an explicit return undef is that≈contrary
DC> to most people's expectations≈a returned undef isn't always false.
i always teach to use plain return and i have some more ways to defend
it. one is that return undef is true if called and assigned to an
array. i use this to detect an actual undef as data vs no return at
another point is that plain return allows the caller to decide what to
do with the return. it can be assigned to an array (to become empty) or
to a scalar. if they want a scalar value in a list context they can wrap
it in scalar (this happens as the OP did in a hash assignment or in
nested sub calls). if you return undef then you can't control the return
value. a call in a list of values where you want it to reduce to an
empty list can't be done in that circumstance as you will always have a
real undef element in the list. the caller needs to know the context of
what they want and plain return allows that control.
Uri Guttman ------ uri at stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
More information about the london.pm