cleanest way to have globals in a CGI
Hello, I am the author of a CGI written in Perl (a single file) which is publicly available. Currently there are some file-scoped lexicals used in routines and I would like to change that in the next release in case anyone wanted to run it under Apache::Registry. Since there would be just one Perl interpreter I guess plain use vars would add symbols to a in principle shared by more code main namespace, do you know whether there is a standard, clean solution for this? -- fxn
RE: cleanest way to have globals in a CGI
use them in a package and call like: $MyPackage::var1 or use object orientation... or just use the vars pragma... -Original Message- From: F. Xavier Noria [mailto:[EMAIL PROTECTED]] Sent: Monday, February 18, 2002 4:04 PM To: [EMAIL PROTECTED] Subject: cleanest way to have globals in a CGI Hello, I am the author of a CGI written in Perl (a single file) which is publicly available. Currently there are some file-scoped lexicals used in routines and I would like to change that in the next release in case anyone wanted to run it under Apache::Registry. Since there would be just one Perl interpreter I guess plain use vars would add symbols to a in principle shared by more code main namespace, do you know whether there is a standard, clean solution for this? -- fxn _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: cleanest way to have globals in a CGI
On Mon, 18 Feb 2002 15:04:16 +0100 Me myself [EMAIL PROTECTED] wrote: : Since there would be just one Perl interpreter I guess plain use vars : would add symbols to a in principle shared by more code main namespace, : do you know whether there is a standard, clean solution for this? I somehow was thinking packages are mainly used for writing modules or classes and that wouldn't be idiomatic to start a CGI with a package declaration. Silly me, packages introduce namespaces and that is precisely what was needed. Nevertheless, it turns out that Apache::Registry takes care of that problem wrapping CGIs in corresponding different packages he declares, so a valid answer to my question appears to be that a standard, clean solution is to do nothing special to protect globals. -- fxn
