SPUG: flip-flops
dancerboy
dancerboy at strangelight.com
Wed Feb 6 06:15:10 CST 2002
At 12:00 am -0800 2/6/02, Colin Meyer wrote:
>Hi Jason,
>
>On Tue, Feb 05, 2002 at 08:24:30PM -0800, dancerboy wrote:
>> At 4:15 pm -0800 2/5/02, Colin Meyer wrote:
>> >
>> >I really like the flip-flop operator. It reminds me of learning boolean
>> >logic by wiring together nand gates. It's also incredibly useful in
>> >one liners:
>> > # print out the contents of <foo> </foo> tags:
>> > pyx file.xml |perl -ne'print if /^\(foo/../^\)foo/' |pyxw
>> >
>> >Have fun,
>> >-C.
>> >
>>
>> Ugh. Reading that section of the docs made my brain hurt. For code
>> that anyone else is going to have to read, please consider
>> implementing .. with "normal" boolean operators (and, or, not)
>> instead. Some language features are best left unused, IMO.
>> (Remember, TMTOWTDI...)
>>
>> -jason
>
>How about suggesting an easy-to-read substitute for scalar .. using
>"normal" boolean operators?
>
>Here's the above perl one liner so rendered:
>
> #!perl -n
> if (not $in_foo and /^\(foo/) { $in_foo=1 }
> print if $in_foo;
> if ($in_foo and /^\(foo/) { $in_foo=0 }
>
>I find the scalar .. to be far more readable. Having once gone through
>the learning process (reading the painful docs), it is easier to use
>than the wordier alternative.
>
>I found the learning process for regular expressions to be far more
>difficult than that for understanding scalar .. . I think that
>anyone would agree. To avoid that painful learning process, one
>could loop across a string character by character and use "normal"
>conditional constructs to test for or extract certain data. Who
>would recommend that? ;-)
Perhaps my complaint should more properly be with the docs, rather
than with the operator itself. To be perfectly honest, I read and
reread that section of the docs, and eventually just gave up; I
*still* don't fully understand what .. and ... do in scalar context.
And I don't think that I'm particularly dense when it comes to things
like this -- if I had difficulty understanding it, I'm pretty sure
most other developers will have difficulty with it as well. It's
possible that, if the docs contained a more coherent explanation of
what these things do, I might change my opinion. But given the
current state of the docs, I'd say scalar .. is going to be difficult
for the average Perl developer to decipher.
OTOH, my complaint may be that, if I understand the docs correctly
(and again, I'm not sure that I do), it appears that the .. and ...
operators implicitly maintain state information from previous uses of
the operator. I consider that to be a Bad Thing: the result of an
operator should be completely determined by its *current* operands,
regardless of any previous uses of the operator. Any sort of state
information should be made explicit (such as storing it in a
variable, e.g. $in_foo in your example above, or encapsulating it in
an object). By utilizing implicit state changes, you are in effect
hiding important parts of the logic of your code, thus making it
harder to read. ("Hiding" here should be understood in the bad sense
of "obscuring", not in the good sense of "encapsulating". There's a
difference, albeit a subtle one.)
Again, just because a language has certain features, doesn't mean
that you ought to use them. (And again, I'm talking about code that
other people may have to read. If scalar .. is clear to you, and
you're the only one maintaining the code, hey, more power to you...)
-jason
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
For daily traffic, use spug-list for LIST ; for weekly, spug-list-digest
Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org
More information about the spug-list
mailing list