> On Tue, 28 Sep 2004, Errin Larsen wrote: > > > On Tue, 28 Sep 2004 18:51:12 +0800, Edward Wijaya > > <[EMAIL PROTECTED]> wrote: > > > > > use vars qw($f); > > > > The above is good, but is now obsolete. > > That is debatable. >
Please, beginners, recognize the above word, *debatable*!! I disagree with the suggestion and feel that in many, many cases you will be better off targeting newer features, especially since many times programs are not distributed. Once you get to a point of distribution, *and* someone requests that you backport your script then make the change, it is just as easy to go in reverse when necessary, than to deny yourself the use of a tool that was added for good reason. I don't expect my opinion to be right, especially in all situations, but if you read this post then you *need* to read the whole page that Chris linked to so that you can see what other's thoughts were on the subject. > Gather round, and listen to the story of a log handling utility > written in perl, and a frustrated user. He's not a perl programmer, > he's a Solaris sysadmin. For him, perl is just a tool, just another > language. And the version of perl shipped with his Solaris is > 5.005_03. > > He is disinclined to build and install a new version of perl just > to support a single tool. After all, he doesn't have to build > new versions of awk, or new versions of C. Why should perl be any > different? > Well then to me he is disinclined to use the tool, to each his own, "don't let the door hit you on the ass on the way out" is an acceptable answer, and often should be given more.... > Trouble is, the author of this tool didn't agree. He had used > our variables instead of my. Which, of course, don't work in > 5.005_03. The user was quite prepared to ditch the tool altogether > and find another because it didn't Just Work. I suggested that he > go through it replacing our with my and lo and behold, it worked. > Of course, equating 'my' with 'our/use vars' we all know to be wrong... don't we. > The moral of this story is that even if you have the latest and > greatest perl, you shouldn't use the latest and greatest features > unless you absolutely must. Because if you do you will severely > limit who will use your code. our in particular is really only a > convenience, saving a few key strokes at most. So don't use it. > Ever. > This is opinion taken out of context, and stated as a rule rather than a suggestion, which may be a bit over the top. > I'll buy a crate of beer for the first person who can show me some > real-world code which absolutely requires our and can't be > re-written to use my <update>or use vars (cos I meant to say that > originally as well)</update>. > > <http://www.perlmonks.com/index.pl?node_id=393423> > > The latest & greatest is only worth using if: > I disagree completely. Two words, "buffer overflow". See an M$ bug list for more.... If this were the case then we would all be writing in assembly...... > * it really does offer you something you need > * it really does offer you something that wasn't available before > * you really don't have to worry about portability > * there really aren't downsides to using it > > For most people, in most cases, one or more of these won't be true. > > It's worth it to be aware of the downsides of using a modern feature > like `our`, and to be confident that it really does make more sense to > use it over some older approach. It may be that the new ways really are > better -- I'm certainly not against progressing the language -- but if a > new feature breaks otherwise good code, is it worthwhile? > Definitely worth knowing about the downsides, but I would push the other direction, is it worth not using something that benefits to prevent something that may never happen? > > -- > Chris Devers > http://danconia.org -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
