Re: Module Naming Dilemma

[gaal]

How about coding like this?

our $Customer  = 'My::Company::Namespace::Customer';
our $Preferred = 'My::Company::Namespace::Customer::Preferred';

my $cust = $Customer->new;
my $pref = $Preferred->new;

This isn't too bad from a usability perspective. It requires no cleverness to get the correct first arguemnt to the two new subs. It might make updating your code to use a subclass a little easier.

Variations on this idea: a constant. Or a sub that decides at runtime which classname to return.

[jdporter]

gaal++, that is quite right. People often forget that class names are just package names, and package names are strings. Which means they can be stored in scalars.

One of the patterns I use a lot is Strategy, in which you typically select (programmatically) between several strategy classes to implement some piece of your application. One of the nice things about Perl is that class names are ordinary objects. So I can do things like this:

use Output::Console;
use Output::Tk;

my $output_strategy = -T STDOUT ? 'Output::Console' : 'Output::Tk';

my $output = $output_strategy->new();

The same principle could be used to shorten long class names.

[ihb]

I prefer having a variable too. I'd even do

  our $Customer = My::Company::Namespace::Customer::; # <--- trailing 
+colons!

to make sure that I didn't mistype the class name. (See Re: Capitalized subroutine names and packages.)

Variables has the extra advantage of expanding right:

  # Hi, this is written by me, the maintainer.
  do_something_with_class(Customer => \&callback);
  # Oops, I missed that Customer really was a
  # subroutine mimicing a bareword. *That* took a
  # while to figure out, huh!

Generally, I don't like to make stuff look like something it isn't.

ihb