Re: How not to hardcode a package name?

Personally, I don't have much problems with "hardcoded" package name, but, looking at your code fragment, I wonder, "why have another class anyway?". Wouldn't the code just work if you remove the line "package Array::Extract::Work;" and use

$class->SUPER::import(ARRAY => __PACKAGE__);
[download]

Comment on Re: How not to hardcode a package name? Download Code

Replies are listed 'Best First'.
Re^2: How not to hardcode a package name? by blazar (Canon) on Aug 28, 2008 at 10:52 UTC
As I wrote, one reason is that I my code is modeled on a fragment from autobox's docs. But then as I also wrote, this is just one possible situation in which a similar case of (what I call) "double hardcoding" may happen. More seriously, the additional class is indeed a worker class, and is just there to keep things separated and clean: in a more realistic example, `Array::Extract` may have its own subs and methods, and I rightly want to define separately the methods that will work on autoboxed objects. `--` ~~If you can't understand the incipit, then please check the IPB Campaign.~~	[reply] [d/l] [select]
Re^3: How not to hardcode a package name? by JavaFan (Canon) on Aug 28, 2008 at 13:10 UTC
True, but realize that when your codebase get larger, you may want to put the 'Array::Extract::Work' code in its own file, and you'll have the package name "hardcoded" in four different places: 1) the pathname of the file containing the Array::Extract::Work package; 2) the package statement in said file; 3) the use statement that tells perl to compile the code in the file; 4) the reference in the import routine. Be careful to not pick a solution that later on makes it harder to separate out the Array::Extract::Work to its own file.	[reply]