in reply to RE: RE: CGI.pm for CSS, tables, pet tricks
in thread (code)) CGI.pm - CSS, tables... (deprecated by node 50167)

What you say makes sense, davorg.   Do I eliminate the redundancy by removing "my" from each of the second declarations, like so? 

use vars qw($type $expires $css $title $tm $file $mod);
$type    = 'text/html';
$expires = 'now';
$css   = './ybiC.css';
$title = 'CGI, CSS and Tables';
$tm    = localtime;
$file  = '/var/www/htdocs/ybiC.cgi';
$mod   = ctime(stat($file)-> mtime);

[download]

I like "use vars qw() for keeping me mindful of all the script's variables.   But if there are reasons for pitching it and using "my", please enlighten me.

Update: Oops. Had I re-read zdog's reply above, I would have asked this question differently.   <sheepish grin>
    cheers,
    ybiC

Replies are listed 'Best First'.
RE: RE: (3) CGI.pm for CSS, tables, pet tricks (use vars vs my)
by davorg (Chancellor) on Aug 14, 2000 at 19:31 UTC

    zdog's tests would seem to indicate that lexical variables are faster than package variables, so if speed is important to you go with my, otherwise I don't know of any reason to choose one in preference to the other so just go with whatever you feel most comfortable with.

    --
    <http://www.dave.org.uk>

    European Perl Conference - Sept 22/24 2000, ICA, London
    <http://www.yapc.org/Europe/>
[reply]

      The general rule I follow is to use my unless there is a reason to use our (or use vars) to make package variables (A.K.A globals). There is only one reason to use globals: because you want to access them outside of their lexical scope. Reasons you'd want to do that include:

      • You want to export them from your package.
      • You want to allow external code to access them by giving a fully qualified name (this usually isn't a good idea).
      • You want to use them higher up in the file than you declared them at (this usually isn't a good idea).
      • You want to declare them within a block but use them outside of that block (this usually isn't a good idea -- though I can see it in rare cases involving BEGIN blocks).
      • You want to access them via a "symbolic reference" (this usually isn't a good idea).

      Note that using our won't let you do any of these except the first and last one.

              - tye (but my friends call me "Tye")
[reply]
[d/l]
[select]

In Section Code Catacombs