Bryan asked:
> What about filetests that already return something meaningful? I'll
> assume that they still behave the same. (And thus, shouldn't be
> chained. Unless you're doing something weird.)
Yep.
> It's also mentioned that they don't short-circuit, so what do
> post-failure tests test against? (I'll assume 'undef', which a test
> will also return 'undef' against.)
Effectively, yes. Actually it's likely to be (the equivalent of) a stat
buffer with its 'is false' property set, so that each test can
short-circuit internally and propagate the failure.
> ** Miscellaneous
>
> Why 'operator:+' instead of 'operator::+'? (Other than the
> potential verbosity required to declare operators within a
> particular package.) I would think it more intuitive to think of
> 'operator' as a provided package (within every package).
>
> Hmm, lexicals.
Yep. Overloaded operators will be inherently lexical (to keep them from
running amok), so they can't be in packages.
> ** Unary _
>
> Space or no space?
Space
> sub _mysub {}
> $a = _mysub;
>
> Which behavior is changing?
No behaviour is changing. Underscore in identifiers has precedence over
underscore as an operator.
> ** Binary //
>
> Was a test for definedness *and* truthfulness considered?
Err... the || operator *is* a test for that.
> Personally, I test for both, particularly within the context of
> defaulting. Of course, you could still write:
>
> $a = ($a // $b) || $b;
No need for the parens, there. // and || are of the same precedence and
left-associative.
Actually, no need for the // either. The assignment has exactly the same
effect as:
$a = $a || $b;
Damian
