[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: expressions vs. statements
Michael Fischer <michael@visv.net> writes:
[...]
> You already know that a function or block "returns" the last statement
> contained within it. So why would you ask Perl to do what you did not
> want it to do?
i'm just saying it can be hard to maintain. Let me give a full example:
----------------------------------------
package fsedit;
sub add {
my ($hd, $part, $all_hds, $options) = @_;
isSwap($part) ?
($part->{mntpoint} = 'swap') :
$options->{force} || check_mntpoint($part->{mntpoint}, $hd, $part, $all_hds);
delete $part->{maxsize};
if (isLVM($hd)) {
lvm::lv_create($hd, $part);
} else {
partition_table::add($hd, $part, $options->{primaryOrExtended});
}
}
----------------------------------------
How do I know wether fsedit::add returns a useful value or not? I can't
without having a look at both lvm::lv_create and partition_table::add. And
even with this, maybe fsedit::add just don't care about those results.
Adding a comment won't help, someone may use the return value without
fsedit::add being aware. One solution would be to return explictly undef or
''. But even with this, it makes fsedit::add hard to understand because you
have to check wether there is "return 1" in the body (which is usually the
case when returning explictly 0 at the end of fsedit::add).
The only good solution i know is very perlish but quite heavy. Maybe I should
use it anyway:
die if defined wantarray;
ensures no one use the function (fsedit::add)
>
> FWIW, in that scenario, you would put the debugging print statement
> as the first statement in each of the conditional blocks, then do
> the rest of whatever was already there.
not if you want to do something at the end of the function.
>
> > > I don't think this issue is terribly important in language design, but
> > > it's obvious to me that the right answer is that most blocks of
> > > sequential statements shouldn't return a meaningful value.
> >
> > agreed for while/for. My only problem is with if_then_else which return value
> > is useful. Alas in perl you can't write "return if () ..." to disambiguate.
>
> No?
[...]
> return if $bar; # returns the special 'undef' value
of course i meant:
return if (...) { ... } else { ... }
one *can* do
return do { if (...) { ... } else { ... } };
but this is rather heavy...