On Fri, Mar 12, 2004 at 12:29:36PM +1100, Deborah Pickett wrote:
: That triggered a thought about unary operators. What about:
:
: $a !=; # i.e., $a = ! $a;
Well, an argument could be made that the corresponding syntax is really:
!= $a;
But you have to read the
A <op>= B ==> A = A <op> B
transformation differently. Something more like
A <op>= B ==> <mysterylocation> = A <op> B
where <mysterylocation> turns out to be the first actual term, which
when A is specified is A, and otherwise B. In other words, dropping
the A out gives you both the binary and unary forms:
A <op>= B ==> <mysterylocation> = A <op> B
<op>= B ==> <mysterylocation> = <op> B
That could actually be pretty handy for
+= $a # coerce yourself to numeric
~= $a # coerce yourself to string
?= $a # coerce yourself to boolean
On the other hand, if we did that generally, we'd also get operators like:
\= $a # turn $a into a reference to itself
Yow.
: Obviously that particular example is a syntax error, but perhaps a more
: verbose "self:" version of same would not be.
Well, it's only a syntax error because we say it's a syntax error. But
I do think prefix unarys tend to be more readable than postfix.
But, yes, method calls are essentially unary postfix operators.
In the OO worldview it's perfectly valid to tell an object to do
something to itself. In the functional worldview, of course, keeping
any kind of state is viewed with deep suspicion.
So really, it's just a matter of whether there's a standard syntax for
"negate yourself". I don't think there is a large call for it, since
most objects don't think of themselves as booleans. But if an object
did want to support that behavior, saying
$a.self:!();
would certainly be "self" evident, as it were. It might even come
for free with the Boolean role. But then there's the good question
of whether to allow the unary op:
!= $a;
Some good questions only have bad answers. This might be one of them.
Larry
