in reply to Re: How not to hardcode a package name?
in thread How not to hardcode a package name?

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.

Replies are listed 'Best First'.
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.