Front page | perl.perl5.porters |
Postings from February 2018
Sawyer X wrote:
>I fail to imagine this being less verbose in a signature, rather than
>the subroutine body.
Consider
sub foo :lvalue ($a = return $p, $b = assign_default_b($a)) {
return substr($a // $q, $b // 3, 1);
}
versus
sub foo ($a = undef, $b = undef) :lvalue {
return $p if @_ == 0;
$b = assign_default_b($a) if @_ <= 1;
return substr($a // $q, $b // 3, 1);
}
Observe that the conditions involving the presence of arguments, which
were implicit in the signature with the use of default value expressions,
have to be written explicitly in the body block. There's also a need
for fake default values in the signature. Those aspects add verbosity.
Note also that the conditions have to be written using @_ and argument
indices, adding a maintenance burden over having them in the signature.
The real defaulting code is also separated from the parameter declaration
in the signature, thus making one jump up and down the code when
reading it.
>This isn't the cost of not moving them. The cost is a narrow case of:
I'm not clear what you're trying to say here. You seem to be trying to
say that the situation I described doesn't apply to the lvalue issue?
It would be incorrect to say that. I described costs of having to
move parameter defaulting logic from a signature into the body block.
Putting signatures before attributes of course does not mean that *all*
defaulting logic would have to be moved. It only affects some subset
of default value expressions, likely just those containing return
expressions. Maybe even only on lvalue subs, though implementing that
would be an extra level of trickiness because of the :lvalue attribute
coming late. In the affected situations, the issues that I described
would be free to occur.
>True, but it is an edge case.
Getting the edge cases right matters. Getting them wrong means the
abstractions are broken and users need to worry about whether the edge
cases could occur.
>vs. having signatures that are more visually consistent
Er, what? Consistent with what? Signatures *after* attributes is what
is consistent with the meanings of signatures and attributes.
>I'm sorry. I couldn't follow this.
Perhaps you'd do better reading the actual thread in which it arose.
Though there's quite a lot of it.
>This is also hard for me to follow. Is the summary that we would not be
>able to make direct references @_ that appear in the body of an
>@_-suppressed body an error?
Pretty much.
-zefram
Thread Previous
|
Thread Next