On the other hand, I suspect most people will end up declaring it
int method self:rotate (int $a is rw) {...}
in any event, and reserve the =rotate for .=rotate, which can never put the = on the left margin, even if we let ourselves have whitespace before POD directives. So maybe we just require self: for the declaration, and forget about = there.
Yes please!
It interacts badly with global names anyway. Is it "*=sort" or "=*sort"? With "*self:sort" it's more obvious.
Agreed. I'd *very* much prefer to see "reflexive" methods like this declared C<self:methodname>. From a readability stand-point, if for no other reason.
Another interesting question, if the "postfix:.=foo" mess is defined with as self:foo, should infix:+= be defined as self:+ instead? In other words, should the <op>= syntax really be a metasyntax like hyperoperators, where you never actually have to define a C<»+«> operator, but the hyperoperator is always autogenerated from ordinary C<+>? So basically any infix:<op>= gets remapped to self:<op>.
I think that would be cleaner.
On the other hand, it also means that someone can say silly things like:
$a cmp= $b $a ~~= $b
I suppose we could simply disallow meta-= on non-associating operators. Can anyone come up with a non-associating binary operator that *should* have an assignment operator? The basic definition of non-associating seems to be that the type of the arguments is incompatible with the type produced by the operator. Which is precisely the problem with something like
$a cmp= $b
insofar as $a is being treated as a string at one moment and as a boolean at the next.
I think it's "merely" a philosophical problem.
After all, we don't complain when people write:
$a = $a cmp $b;
So should we complain when people write exactly the same thing, only as:
$a cmp= $b;
Stylistically, they're equally as abhorrent, but Perl users aren't expecting the Stylish Inquisition.
The real question is whether the two forms are equally likely to indicate a logic error. One could argue that anyone who writes the first is more likely just being (small-l) lazy, whereas writing the second probably indicates a "thinko". But then one could also argue that it's (small-l) lazier to write the second than the first, so the second is actually *more* likely to be (small-l) laziness than error.
There are also cases where something like:
$a ||= $b;
or:
$a += $b;
changes the type of value in $a. Should we flag those too? Currently we do warn on the second one if $a can't be cleanly coerced to numeric. Would that be enough for C<cmp=> too, perhaps?
Damian
