Thanks again Ken, as I was obviously using the terms incorrectly I appreciate the primer. Would the terms "main" module and "data" module be more appropriate? My intention would be for the user to load the main module, and never have to access the data module directly. So it sounds like a composition relationship (as the data module has things in it that the main module needs to do its work), so NEEDS-A would be a better description for my situation, but I see where you're going with Car::Engine.

In regards to using methods to access data vs. accessing the data directly, I see what you're saying in regards to the examples I've given already, but I have another case that I'm still confused (or maybe just stubborn) about how to handle. My module has two modes of operation. You can either pass it the name of a thing which it uses to look up data related to that thing, and then parse it; or you can pass it a file that contains the data already looked up, and then it parses that. So the constructor can look like this:

my $object = Foo::->new ( thing => "$ARGV[0]" );
[download]

or this:

my $object = Foo::->new ( file => "$ARGV[0]" );
[download]

Then at various places in the code I do things like this:

if (not defined $self->{file}) {
[download]

to determine which mode I'm in (this is all within the main module). There are also a couple of options that the user can pass in the constructor, and various other things which it's just easy to stuff into the object which I also access the same way (again, all in the main module).

Given that it's me doing the access in the module itself, and not a published interface to the data, is that Ok? Or do I need to access that data internally via a method as well? That would seem pretty inefficient to me. I do use the convention of prefixing things which I intend to be "private" with an underscore, so that if the user goes poking around in the code they will at least get a clue that they are messing with something they should not, that is subject to change, etc. But if there is a better way to do that, I'm definitely open to it.

And your gentle hint about learning the markup is well taken. I will try to pick that up as time goes on.