Re^2: How not to hardcode a package name?

package Array::Extract; our $worker_pkg; ... package Array::Extract::Worker; BEGIN { $Array::Extract::worker_pkg = __PACKAGE__ }
[download]

I didn't know I could do that. Or better: I hadn't thought I could do that. Of course the nice point is that in the BEGIN block I don't need to specify the full package name of $worker_pkg, since our creates an alias to it in all the lexical scope surrounding it.

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.

Update: I choose BEGIN out of habit, maybe something later like CHECK or INIT might be better, but then again they might cause problems with mod_perl.

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...

--
~~If you can't understand the incipit, then please check the IPB Campaign.~~

Comment on Re^2: How not to hardcode a package name? Select or Download Code

Replies are listed 'Best First'.
Re^3: How not to hardcode a package name? by moritz (Cardinal) on Aug 28, 2008 at 10:57 UTC
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.	[reply] [d/l] [select]
Re^4: How not to hardcode a package name? by blazar (Canon) on Aug 28, 2008 at 12:32 UTC
Corion pointed out that this approach does "action at a distance", which you probably can't entirely avoid unless you do symbol table hackery. Actually that's what I (wanted in the first place and) wanted to point out myself in my previous reply -except that I forgot to- to the effect that if I was to adopt that technique, then I would put a well visible comment (and I'm the "self explaining code does not need comments" kinda guy!) besides `our $worker_pkg;` (or my...) `--` ~~If you can't understand the incipit, then please check the IPB Campaign.~~	[reply] [d/l] [select]