perl style and returning from function?

[Bill]

What do you think is better:

....
return ($rc and $rc == 1) ? 1 : 0;
}

or

$rc and $rc == 1 and return 1;
return 0;
}

This is for a function that does some processing and then returns 1 on
success and 0 on failure.

Opinions?

 

[Ben Morrow]

Quoth (e-mail address removed) (Bill):

What do you think is better:

...
return ($rc and $rc == 1) ? 1 : 0;
}

or

$rc and $rc == 1 and return 1;
return 0;
}

return $rc == 1 ? 1 : 0;

Perl is not C. A value of undef will quite happily be != 0.

A better answer altogether might be

$rc == 1 and return 1;
return;

which will always return false, even if called in list context.

Ben

 

[Uri Guttman]

BM> Quoth (e-mail address removed) (Bill):
BM> return $rc == 1 ? 1 : 0;

why not just return $rc == 1? the OP didn't specify what the false value
must be.

BM> Perl is not C. A value of undef will quite happily be != 0.

but it will trigger an uninitialized warning. but the OP wasn't testing
for undef.

BM> A better answer altogether might be

BM> $rc == 1 and return 1;
BM> return;

i prefer:

return 1 if $rc == 1 ;
return ;

then the returns line up prettily

uri

 

[Ben Morrow]

BM> Quoth (e-mail address removed) (Bill):

BM> return $rc == 1 ? 1 : 0;

why not just return $rc == 1? the OP didn't specify what the false value
must be.

Yes he did. He specified 0. (IMO that is a bad specification, but...

BM> Perl is not C. A value of undef will quite happily be != 0.

but it will trigger an uninitialized warning.

True. I tend to turn those off, so I tend to forget about them... undef
is too useful to be warned about .

but the OP wasn't testing for undef.

No... I was puzzled as to what he thought he *was* testing for, though.
The idiom reminded me of

if (p && *p == 'a') {

in C, and I wondered if that was what the OP had in mind.

BM> A better answer altogether might be

BM> $rc == 1 and return 1;
BM> return;

i prefer:

return 1 if $rc == 1 ;
return ;

then the returns line up prettily

Yes. I would also be inclined to use

$rc == 1 ? return 1
: return;

but that's just because I'm addicted to ?:, and would really like to
have 'then/else' as a low-precedence version:

$rc == 1 then return 1
else return;



Ben

 

[Uri Guttman]

BM> Yes. I would also be inclined to use

BM> $rc == 1 ? return 1
BM> : return;

gack! side effects (in this case flow control) inside ?: is fugly and
nasty! and the return token is duplicated. my rule is to only use ?:
for a value which is its intent. we see newbies all the time doing
assignments in ?: and not getting the precedence issues.

uri

 

[Ala Qumsieh]

BM> return $rc == 1 ? 1 : 0;

why not just return $rc == 1? the OP didn't specify what the false value
must be.

In this case,

return $rc;

should suffice.

--Ala

 

[Uri Guttman]

BM> return $rc == 1 ? 1 : 0;
AQ> In this case,

AQ> return $rc;

AQ> should suffice.

not necessarily. if $rc is 2 he still wants to return 1. the real
question is can he directly return the value $rc == 1? or must the false
value be 0 and not ''?

uri

 

[Paul Lalli]

BM> return $rc == 1 ? 1 : 0;

AQ> In this case,

AQ> return $rc;

AQ> should suffice.

not necessarily. if $rc is 2 he still wants to return 1. the real
question is can he directly return the value $rc == 1? or must the false
value be 0 and not ''?

The original code was
That implies that if $rc is 2, he wants to return 0, doesn't it?

Paul Lalli

 

[Anno Siegel]

Quoth (e-mail address removed) (Bill):

return $rc == 1 ? 1 : 0;

Perl is not C. A value of undef will quite happily be != 0.

It will issue a warning. "$rc and $rc == 1" is sound, but I'd just
return that. It's a legitimate boolean value, after all.

A better answer altogether might be

$rc == 1 and return 1;
return;

which will always return false, even if called in list context.

I'm not sure about this rule in this case. When a function is described
as returning a boolean value, it should return one, imho. I'd like
"map boolfunc( $_), @list" to return as many "true"s and "false"s as
@list has elements, not an indefinite number of all "true"s.

The rule is well applied where the blank return indicates failure to
deliver the normal result, but not when a result is expected in any case.

Anno

 

[Uri Guttman]

PL> The original code was
PL> That implies that if $rc is 2, he wants to return 0, doesn't it?

yes, but i would like a proper spec from the OP. assuming $rc is defined
then just return $rc == 1 is enough (and also assuming $rc is a number).

uri

 

[Bill]

Yes he did. He specified 0. (IMO that is a bad specification, but...


True. I tend to turn those off, so I tend to forget about them... undef
is too useful to be warned about .


No... I was puzzled as to what he thought he *was* testing for, though.

To clarify, this is a database access function that should modify
exactly one row. In an error state relative to the intended outcome,
no rows or more than one row could have been modified.

$rc could be undef, or defined but not one, which would still be an
error. The function is specified to return a boolean, defined value
that is 1 if $rc is 1 and false (but defined) otherwise. I guess
either 0 or '' should work?

 

[Bill]

I'm not sure about this rule in this case. When a function is described
as returning a boolean value, it should return one, imho. I'd like
"map boolfunc( $_), @list" to return as many "true"s and "false"s as
@list has elements, not an indefinite number of all "true"s.

The rule is well applied where the blank return indicates failure to
deliver the normal result, but not when a result is expected in any case.

Anno

It seems that Perl 6 will havew a 'boolean context' operator, so that
(I think)

? $rc and $rc == 1

will always return a boolean, which I guess means it will return
either 1 or 0. Can Perl 5 be streched onto that rack?

 

[Ben Morrow]

Quoth (e-mail address removed) (Bill):

It seems that Perl 6 will havew a 'boolean context' operator, so that
(I think)

? $rc and $rc == 1

will always return a boolean, which I guess means it will return
either 1 or 0.

^^ undef, not 0, I'd guess.

Can Perl 5 be streched onto that rack?

!! $rc will boolify $rc. What would be more useful in this context would
be if (I don't know whether this will happen or not) the explicit numify
operator '+' *didn't* warn about conversion from undef, so that

+$rc == 1

would do what is required with no warning.

Ben

 

[Rocco Caputo]

To clarify, this is a database access function that should modify
exactly one row. In an error state relative to the intended outcome,
no rows or more than one row could have been modified.

$rc could be undef, or defined but not one, which would still be an
error. The function is specified to return a boolean, defined value
that is 1 if $rc is 1 and false (but defined) otherwise. I guess
either 0 or '' should work?

# Return true if $rc is 1; false otherwise. The C<$rc &&>
# avoids a warning if $rc is undefined. C<==> has a higher
# precedence than C<&&>, so it's all good.
return($rc && $rc == 1);

-- Rocco Caputo - http://poe.perl.org/

 

[Sara]

The original code was

That implies that if $rc is 2, he wants to return 0, doesn't it?

Paul Lalli

sub x
{ code
code