develooper Front page | perl.perl5.porters | Postings from May 2008

Re: [perl #54974] Strange map {} Behavior When Returning Two Values

Thread Previous | Thread Next
Glenn Linderman
May 30, 2008 18:50
Re: [perl #54974] Strange map {} Behavior When Returning Two Values
Message ID:
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 <> [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 --
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking

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