[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...