At 13.31 -0400 2000.05.25, Horsley Tom wrote: >Just some examples: perl has about 1,247 levels of operator >precedence, and some fools out there actually insist >on minimizing the number of parens in any expression >by picking || instead of OR, etc. No ordinary human >being can actually parse crap like that - I'd much >rather have the "ugly" parens cluttering things up just >so I'd know, not only what the expression really means, >but what the author really meant when he wrote it, >in some ways APL is more readable :-). If you cannot understand this: if ($x == 1 || $y == 2) { then I don't know what to say. I just cannot fathom how that is hard to read. On the other hand, if you think this is hard to read: my $mode = (ref $hash->{CALLBACK} eq 'CODE' ? kAEQueueReply : (exists $hash->{REPLY} # check event setting ? $hash->{REPLY} : exists $self->{REPLY} # check global setting ? $self->{REPLY} : 1 # default to wait ) ? kAEWaitReply : kAENoReply) | (exists $hash->{MODE} ? $hash->{MODE} : exists $self->{MODE} ? $self->{MODE} : (kAECanInteract | kAECanSwitchLayer)); well, then I deserve the flogging I get for it. :-) But it is not the lack of parens that make it hard to read (or the ugliness of the constants, which I won't address, blame Apple if you'd like to), it is the complexity of the statement. It should be broken up for better readability. I put this here to show that I don't think it is so much parens that are a problem as often as it is a programmer's unwillingness to break up a complex statement into smaller statements. I understand this unwillingness somewhat, since I clearly have fallen prey to it myself, as above. But at least I have some useful comments, right? And note that again nothing above has anything to do with Perl, aside from the fact that it happens to be written in Perl. The only reason I wouldn't write something this ugly in C is because I am not comfortable enough in C to be that ugly. But I am sure I could if I set my mind to it. I did format the above code so it is readable to me and to perhaps others, but then I think I came up with a good rule of thumb: if you have to spend more time thinking about how to format it for readability than you did thinking about how to code it in the first place, then it probably needs to be rewritten. I might just leave this code in Mac::Glue for as a reminder to myself, however. >You may get the idea: You can be a perfectly competent >programmer, writing perfectly wonderful perl code >and it can *still* be virtually impossible for someone >else to maintain. I dunno, I am not sure I buy it. Can you give us an example of well-written Perl code that would be very difficult for another reasonably competent Perl programmer to maintain? -- Chris Nandor | pudge@pobox.com | http://pudge.net/ Andover.Net | chris.nandor@andover.net | http://slashcode.com/