develooper Front page | perl.perl5.porters | Postings from July 2010

RE: Order of evaluation of terms (was peephole optimiser could prune more dead code)

Thread Previous | Thread Next
Jan Dubois
July 15, 2010 13:51
RE: Order of evaluation of terms (was peephole optimiser could prune more dead code)
Message ID:
On Thu, 15 Jul 2010, David Golden wrote:
> I was amusedly thinking that it's not guaranteed to hold true when
> "evaluating" "a" and "b" have magic anyway.  (e.g. "a" is tied to
> increment when evaluated and "b" is tied to do something as a function
> of a.
> And then we come full circle to the debate that spawned this thread
> about what can be assumed about order of evalution.  :-)

My personal opinion is that any FETCH magic or overloaded operator that
has observable side effects is essentially broken and abusing a feature.
You can always use a function or method call if you need exact control
over how your code is being called.

Once you implement magic/overloads that violate the underlying algebraic
relationships in your overloaded operators you will end up in a world
of pain.  E.g. the following expressions should always be true:

    ($a + $b) == ($b + $a)
    ($a < $b) == ($b <= $a)
    "$a" eq $a
    ($a eq $b) && ($b eq $c) == ($a eq $c)

Perl has different operators for e.g. "==" and "eq", or "+" and "." for
a reason. Don't overload them with semantics that contradicts their
intrinsic behavior!

Once you accept these rules (no side-effects, self-consistent behavior),
the order of evaluation becomes a non-issue. 

Perl allows you to shoot yourself in the foot.  We should not have to go
out of our way to guarantee that we always hit the same foot...


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About