From: "Dave Storrs" <[EMAIL PROTECTED]>
To: "Chris Hostetter" <[EMAIL PROTECTED]>
Sent: Sunday, June 10, 2001 9:07 PM
Subject: Re: suggested properties of operator results
> On Fri, 8 Jun 2001, Chris Hostetter wrote:
> > $v2 = VALUE2;
> > $v1 = (defined VALUE1.valueR ? VALUE1.valueR : VALUE1);
> > return ($v2-$v1 == abs($v2-$v1)) is valueR($v2);
> >
> > which ... would cause the following code to mean ... think it
> > should mean:
> > if ($foo < $bar < $baz) { ... }
I'm assuming that you're correct (I see no reason that you wouldn't be; I
just havn't checked it out myself, and am not clear on where "valueR" is
defined.)
...
> 1) The "do this because it will be more intuitive for beginners"
> argument comes up a lot, and is pretty appealing at first. However, as
> someone (was it tchrist?) pointed out, beginners don't stay beginners for
> long, so writing a language for beginners may cost you people when they
> "grow out of" your language.
Which it is indeed. (The feature is a good idea, and tchrist is right.)
It's a lot easier to read, and a lot easyer to write ($a < $b < $c) then
($a<$b) && ($b<$c). Moreover, when the varables have names longer then a,
b, and c, then it gets rather easy to change only one of several instances
of a varable. (That is, $a<$b && $b<$c into $a<$d && $b<$c).
> 2) This feature would be very prone to abuse (makes it easier to
> obfuscate code), but that isn't a reason to disqualify something either.
Certianly not in perl. Hell, I think sometimes it's a reason /to/ put a
feature in perl.
> 3) Used for what it is intended for, it seems like a very concise,
> expressive way to do multiple relationship tests without needing all those
> "&&"s and such.
Indeed. (Though, as defined above, this won't work on the string
operations, only the numerics.)
-=- James Mastros
