You are asking where in the file system the class source code should live? I guess the answer is anywhere you care to put it.

The naming of perl classes does no imply inheritance, so if B is a sub class of A, you don't have to name them MyCompany::A and MyCompany::A::B. You can if you like, and in many places that is the coding convention, but there is no requirement to do so from the language.

Conversely, If A and B are not related to each other through class inheritance, then neither the language, nor any coding convention I have come across says anything about how you should name the classes. You can do whatever you see fit.

Sorry I can't provide an answer, but I don't think your question has one.

I agree that your question is very hard to fathom.   Perhaps if you could explain your situation in more detail to us, you would get more-useful answers.

I would say, though, that you really do want @INC to serve its intended purpose:   that you really don’t want to write code that is dependent upon the layout of the file-system.   You should be dealing only with package name-spaces, expecting that when you use or require one of those names, “it miraculously appears,” and you don’t care from whence it came.

This whole design-concept smells vaguely fishy to me.   It is a familiar smell, and I have learned not to like it.   “My elvish sword has begun to glow,” and somewhere in the distance I seem to hear a familiar lament, “abandon all hope, ye who enter here ...”   I suggest that you contemplate carefully just where you are trying to go, and that you not cling too tightly to your present notions of how to get there.   As they used to say, “smoke it over, a little more.”

Module AAA::A would include a package AAA::A; directive, would be loaded using use AAA::A; and would be stored in file $private_lib/AAA/A.pm. The script or module loading AAA::A would have to know to look in $private_lib so @INC would have to be set up properly already, perhaps using use lib or env var PERL5LIB.

The point people are trying to make is that the file naming specifies nothing about the relationship between the classes.

These file layouts are all valid:

A.pm
B.pm

A.pm
A/B.pm

B.pm
B/A.pm

AB/A.pm
AB/B.pm

Foo/A.pm
Foo/Bar/B.pm
[download]

It's what's inside the files that determines inheritance, not the names of the files themselves.

Include the following before you use any of your private modules:

BEGIN { push(@INC, $ENV{'HOME'} . '/lib'); }
[download]

So, for example:

#!/usr/bin/perl

use strict;
use warnings;

BEGIN { push(@INC, $ENV{'HOME'} . '/lib'); }

use Foo::A;
use Foo::Bar::B;

my $a = Foo::A->new();
my $b = Foo::Bar::B->new();
[download]

Succint wasn't requested--rather the opposite: More detail would be helpful.

...roboticus