On approximately 5/30/2008 7:27 AM, came the following characters from the keyboard of Abigail: > On Thu, May 29, 2008 at 03:16:31PM +0200, Aristotle Pagaltzis wrote: >> * H.Merijn Brand <h.m.brand@xs4all.nl> [2008-05-29 13:00]: >>> using a semi-colon >>> $ perl -wle'my@a=map{;"--$_"=>$_}@ARGV;print"(@a)"' foo bar >>> (--foo foo --bar bar) >>> >>> using parens >>> $ perl -wle'my@a=map{("--$_"=>$_)}@ARGV;print"(@a)"' foo bar >>> (--foo foo --bar bar) >>> >>> using a unary + >>> $ perl -wle'my@a=map{+"--$_"=>$_}@ARGV;print"(@a)"' foo bar >>> (--foo foo --bar bar) >>> >>> using catenation >>> $ perl -wle'my@a=map{"--".$_=>$_}@ARGV;print"(@a)"' foo bar >>> (--foo foo --bar bar) >>> >>> I personally think that using parens here to disambuigate is >>> the most verbose option without adding unexplainable line noise >> Which in my mind makes it the least desirable, since that makes >> it ???obviously??? superfluous and therefore the most likely to be >> removed by some overeager maintainer. The semicolon, OTOH, is so >> unusual that it is much more obviously intentional, even if the >> maintainer who discovers it doesn???t know what it???s there for. It >> probably won???t prevent them from removing it, but I would expect >> that after the code breaks they will conclude that the semicolon >> was put there purposely to prevent that error. With parens, in >> contrast, it seems more likely to me that the maintainer will >> think the code worked just by accident because the previous >> programmer wrote it in a peculiar style with no particular >> intent. > > > I guess it's matter of style, but I prefer the parenthesis as well. The > semi-colon is unual enough that it mystefies many people. The overeager > maintainer who removes the parenthesis will be left code that doesn't > compile, let alone pass a test suite. I'm not so worried about that; > it'll be a simple delete 2 chars, compile, undo cycle. Worse would be > a maintainer that wastes half a day what the hell the semi-colon is for. I find it amusing that no one that has suggested varieties of "parser work-around syntax" has suggested adding a small comment to help out the future maintainer of the code. # {()} in next line required to determine {} is not an anonymous hash Instead, there are all these suppositions about which techniques the future maintainer is likely to best intuit, that person clearly being someone of inferior intelligence than these brilliant coders that aren't willing to write a comment, when using a construct that the Perl parser and tokenizer needs help to comprehend. After all, since it is documented, why should it be commented too? -- Glenn -- http://nevcal.com/ =========================== A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration NetworkingThread Previous | Thread Next