Front page | perl.perl5.porters |
Postings from October 2016
Sam Kington wrote:
> this => $this, # might be undef or blank
$this can be undef, but it can't be an empty list, or in general anything
other than one list element. So "$this // undef" which you expand this
to is redundant.
> that => get_that_maybe()
A sub call can yield any number of list elements, so this is the
one that needs attention (which in this example you didn't give it).
You've talked about a sub call yielding an empty list, but you omitted to
mention the possibility of it yielding more than one value. The effect
you're looking for for your `mandatory' fat comma is simply to put its
rhs into scalar context, which is what "scalar()" or "// undef" does.
>my %thing_params = (thing => $thing);
>$thing_params{this} = $this if $this;
>if (my $that = get_that_maybe()) {
> $thing_params{that} = $that;
>}
>do_thing(%thing_params);
can be written inline as
do_thing(
thing => $thing,
($this ? (this => $this) : ()),
do { my $that = get_that_maybe(); $that ? (that => $that) : () },
);
>And that's annoyingly messy. It would be a lot nicer if there was
>an infix operator that acted like the fat comma, but gobbled the lhs if
>the rhs was undef or missing:
Ah, but what should that condition be, exactly? Is it only undef that
means the key should be omitted? That's not the condition you used in
the above example, where you tested truthiness, not definedness, of both
$this and $that. That is, should "0" be a null value alongside undef?
It acts as a null in your example above, but not in the criterion you just
stated. And there's the rub: the condition controlling whether the key
should be included varies between situations. No single "=>?" operator
can handle even the most common variations. Whereas the existing ?:
operator can handle any condition.
-zefram
Thread Previous
|
Thread Next