The problem is that an object, by definition, encapsulates its data. And yet you wish to externalize some portion of the object's encapsulated data so that it's available to any subs in the package, inaddition to object methods. That's messy. Furthermore, an object is usually "an" instance of a class, not "the" instance of a class. That means you can have several object instances of a class, each with its own separate object data. If there is to be a piece of class data that is the same for all object instances, your use of the global variable is the cleanest solution I can think of, so why jump through hoops to figure out a way to eliminate it?

An object's data isn't intended to be available before the object is created, and yet still unique to the object. You may be able to come up with some contortion using an inside-out object where objects are clones of some parent datastructure, but that's no better than what you've got now, and definately harder to maintain.

I guess my question is why is it so important that you eliminate a package global when it's doing what you want? And would it suffice to create a package-scoped lexical? By creating an outter lexical block that is as broad as the package, and declaring a lexical (my) variable within it, you'll have a variable that looks global to the rest of the package (except there's no entry in the symbol table), but is inaccessible from outside the package (because there's no entry in the symbol table -- assuming that's your goal).