On Tue, 28 Sep 2004 15:26:08 -0400 (EDT), Chris Devers
<[EMAIL PROTECTED]> wrote:
> 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.
> 
>     Gather round, and listen to the story of a log handling utility

<<SNIP>>

> 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?
> 
> --
> Chris Devers
> 

So, what was the justification for changing 'use vars' to 'our'?  Did
the developers just want to shave down the keystrokes?  Was it an
understandability (is that a word?!) issue?  Is there any (deep down,
underneath it all) internal difference between the two?  Is there a
resource to read about this issue?  (I did read the link you supplied,
but it didn't go into WHY this changed.)

The advice I was giving in this thread was based on the following
quote in my 'perldoc Getopt::Std' documentation.  (A quote from that):

     Note that, if your code is running under the recommended
     "use strict 'vars'" pragma, you will need to declare these
     package variables with "our":

         our($opt_foo, $opt_bar);


Later in the docs it DOES say that if you don't want to declare these
as global variables, 'getopts()' will accept a hash reference. 
(Another quote):

     For those of you who don't like additional global variables
     being created, getopt() and getopts() will also accept a
     hash reference as an optional second argument. Hash keys
     will be x (where x is the switch name) with key values the
     value of the argument or 1 if no argument is specified.

Like this:

getopts('oif:', \%opts);  # options as normal. Values in %opts

I have a feeling that that way is the "most correct" way.  That way
the values being grabbed off the command line options will be scoped
specifically where you want them to be instead of being globals.

comments?

--Errin

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>


Reply via email to