|No such thing as a small change|
"In C you would put these values in a .h file."
In C, you wouldn't have multiple namespaces. That's the primary difference here.
In C++, if memory serves, you could have multiple namespaces and then in your .cpp (or .cxx or whatever) file, you would have using std; using object1; ... and there's no way to auto-import a bunch of namespaces, and doing so in the header would defeat much of the purpose of namespaces (they don't export just small pieces like we can in Perl).
And, in my experience, one tarball isn't any more cumbersome with one file in it or a hundred. :-) With very very few exceptions, I would say targeting a single file for deployment is misguided and/or optimistic. You'll end up with a config file, and maybe some data files (e.g., DDL for database deployment), and you'll quickly be beyond a single file anyway. May as well embrace the inevitable from the beginning. You'll also end up with code that's easier to write and maintain.
It's not that you have no choice. It's that it will take you more effort to do than if you were to follow the convention. I do have a module I just wrote for $work the other week that does something similar to what you say. But it's definitely more work to set up than following convention. I've only done this this way because of some experience with our setup that says that this will make things a little easier as we keep forgetting to import some functions that we need nearly everywhere. Normally, that's not an issue, so for everything else, it's use Module; as normal.
If you want MyThing to export the stuff from Object1, check out Import::Into. This might work:
Still more work than normal, but probably will work. Though, again, if you don't know what you're doing, this probably isn't what you want. Use separate files.