in reply to Re^2: How not to hardcode a package name?
in thread How not to hardcode a package name?
Similarly, I may still be using a regular lexical variable. I'm wondering if there are any possible drawbacks/differences/gotchas with one approach wrt the other.
Lexical (my) variable: good encapsulation trough limited scope, but you're forced to keep those two packages in the same file. You can't override it from the outside, which can be both good and bad, depending on whether you favor security or extensibility.
For package variables it's just the other way round ;-)
Corion pointed out that this approach does "action at a distance", which you probably can't entirely avoid unless you do symbol table hackery. my variables limit the scope of the spooky action, though.
I must admit I know next to nothing about those special blocks, and I should probably read up something. Re mod_perl, I'm not a web programmer, but it's good to know anyway. Although I can't understand why: if it's valid Perl, it should continue to work in that environment too...
The various compilation and execution phases are a not-so-simple (but really powerful) beast. CHECK and INIT are not executed inside a string eval, which is documented in perlmod, and apparently (I'm not a mod_perl user either) what mod_perl does to execute its scripts and modules.
I don't know if that's a limitation in the implementation or a design goal, though.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^4: How not to hardcode a package name?
by blazar (Canon) on Aug 28, 2008 at 12:32 UTC |