Prev: LibXML (XPATH) and escape
Next: Module name access
From: Peter J. Holzer on 26 Jan 2010 05:44 On 2010-01-26 09:38, Dr.Ruud <rvtol+usenet(a)xs4all.nl> wrote: > Peng Yu wrote: >> @array=("a", "b", "c"); > > 1. "array" is the stupidest name for an array. [...] > my @word = qw/ a b c /; The name of a variable should tell the reader something about its content and/or purpose. So I would agree that @array is in almost all cases a very stupid name, as it doesn't tell you anything except that it's an array, and it does so redundantly ("@" and "array"). However, in this example, the only thing important is that is an array. It isn't important what kind of data is in the array (except that the elements are strings or can be stringified) or what the data is used for. So @array is ok, because it tells you that this is "just an array". @word, however, is a bad name. It conveys that the array contains "words". This then causes the reader to wonder what a "word" is (an English word? No, "b" and "c" are not English words. Some other natural language? Maybe. Strings matching /^\w+$/? Maybe.) and whether the example is still valid if an element contains data which is not a "word". So @stringifiable_data might be ideal but it's a bit long. @strings is already a bit too narrow (is 1 a string? Is an object with an overloaded "" operator a string?), in about the same sense that @array is too wide. So I don't really see that one of @stringifiable_data, @strings or @array is clearly better than the others. hp
From: J�rgen Exner on 26 Jan 2010 11:39 "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote: >On 2010-01-26 09:38, Dr.Ruud <rvtol+usenet(a)xs4all.nl> wrote: >> Peng Yu wrote: >>> @array=("a", "b", "c"); >> >> 1. "array" is the stupidest name for an array. >[...] >> my @word = qw/ a b c /; > >The name of a variable should tell the reader something about its >content and/or purpose. So I would agree that @array is in almost all >cases a very stupid name, as it doesn't tell you anything except that >it's an array, and it does so redundantly ("@" and "array"). > >However, in this example, the only thing important is that is an array. >It isn't important what kind of data is in the array (except that the >elements are strings or can be stringified) or what the data is used >for. So @array is ok, because it tells you that this is "just an array". Ack >@word, however, is a bad name. It conveys that the array contains >"words". Actually it conveys that @word contains exactly one word, maybe split into individual letters. >This then causes the reader to wonder what a "word" is (an >English word? No, "b" and "c" are not English words. Some other natural >language? Maybe. Strings matching /^\w+$/? Maybe.) and whether the >example is still valid if an element contains data which is not a >"word". If that would have been the intented meaning then @words would have been preferable to @word. jue
From: Peter J. Holzer on 26 Jan 2010 12:11 On 2010-01-26 16:39, J�rgen Exner <jurgenex(a)hotmail.com> wrote: > "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote: >>On 2010-01-26 09:38, Dr.Ruud <rvtol+usenet(a)xs4all.nl> wrote: >>> Peng Yu wrote: >>>> @array=("a", "b", "c"); >>> >>> 1. "array" is the stupidest name for an array. >>[...] >>> my @word = qw/ a b c /; >> >>The name of a variable should tell the reader something about its >>content and/or purpose. So I would agree that @array is in almost all >>cases a very stupid name, as it doesn't tell you anything except that >>it's an array, and it does so redundantly ("@" and "array"). >> >>However, in this example, the only thing important is that is an array. >>It isn't important what kind of data is in the array (except that the >>elements are strings or can be stringified) or what the data is used >>for. So @array is ok, because it tells you that this is "just an array". > > Ack > >>@word, however, is a bad name. It conveys that the array contains >>"words". > > Actually it conveys that @word contains exactly one word, maybe split > into individual letters. [...] > If that would have been the intented meaning then @words would have been > preferable to @word. I, too, prefer using the plural for array names. But there are valid arguments for using the singular: * $word[5] reads more naturally as "word (number) 5" than $words[5]. * In Perl, singular/plural is expressed by the sigil, so @word is already "several word(s)" and the English plural-s is at best redundant and at worst harmful, because Perl doesn't understand it (@words is *not* the array containing $word[0], $word[1], ...). So I consider that a matter of personal style and decided not to complicate this discussion by bringing up the singular/plural debate. I should have known that somebody else would ... hp
From: Dr.Ruud on 26 Jan 2010 13:21 Peter J. Holzer wrote: > On 2010-01-26 16:39, J�rgen Exner <jurgenex(a)hotmail.com> wrote: >> "Peter J. Holzer" <hjp-usenet2(a)hjp.at> wrote: >>> On 2010-01-26 09:38, Dr.Ruud <rvtol+usenet(a)xs4all.nl> wrote: >>>> Peng Yu wrote: >>>>> @array=("a", "b", "c"); >>>> 1. "array" is the stupidest name for an array. >>> [...] >>>> my @word = qw/ a b c /; >>> The name of a variable should tell the reader something about its >>> content and/or purpose. So I would agree that @array is in almost all >>> cases a very stupid name, as it doesn't tell you anything except that >>> it's an array, and it does so redundantly ("@" and "array"). >>> >>> However, in this example, the only thing important is that is an array. >>> It isn't important what kind of data is in the array (except that the >>> elements are strings or can be stringified) or what the data is used >>> for. So @array is ok, because it tells you that this is "just an array". >> Ack >> >>> @word, however, is a bad name. It conveys that the array contains >>> "words". >> Actually it conveys that @word contains exactly one word, maybe split >> into individual letters. > [...] >> If that would have been the intented meaning then @words would have been >> preferable to @word. > > I, too, prefer using the plural for array names. > > But there are valid arguments for using the singular: > > * $word[5] reads more naturally as "word (number) 5" than $words[5]. > > * In Perl, singular/plural is expressed by the sigil, so > @word is already "several word(s)" and the English plural-s is > at best redundant and at worst harmful, because Perl doesn't > understand it (@words is *not* the array containing $word[0], > $word[1], ...). > > So I consider that a matter of personal style and decided not to > complicate this discussion by bringing up the singular/plural debate. > I should have known that somebody else would ... When calling it @word, I hoped for these comments. :) -- Ruud
From: John Bokma on 26 Jan 2010 13:29
"Uri Guttman" <uri(a)StemSystems.com> writes: >>>>>> "JB" == John Bokma <john(a)castleamber.com> writes: > > JB> I wouldn't use it though, but like Abigail, IIRC, once wrote, there is > JB> no reason to have a problem with map in void context because we use > JB> other functions in void context without problems (like print). > > the point with map in void context is not efficiency It used to be, and back then, IMO there was a much stronger argument to not use map in void context. > but in conveying > meaning to the reader. map is intended to generate a list, not execute > side effects. But who decides that map is not intended for its side effects? In Perl there are IMO quite some constructs that are used in somewhat unexpected ways, especially to people new to the language. > for modifier does the same thing and is meant for side > effects as it doesn't generate a list. perl has many related things like > this and you should choose the one with better semantics for your > intentions. map generates lists so use it that way. for modifier doesn't > generate lists so use it for side effects. Like I wrote, I don't like it, and won't use it. But the arguments against using map in void context are more a matter of taste IMO. The "its not intended for that" is weak at best, in my (current) opinion. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development |