You are looking something rather like the (appropriately, given the example) factory pattern. The "method" used to create an instance is the factory.

The following is based on Moritz' sample, cleaned up and tested: :-)

use strict;
use warnings;

package Car;

my %carByType;

sub new {
    my ($class, %opts) = @_;

    return bless \%opts, $class;
}


sub factory {
    my (%opts) = @_;

    die "Don't know how to make a new car"
        if !exists $opts{name} || !exists $carByType{$opts{name}};

    $carByType{$opts{name}}->new(%opts);
}


sub describe {
    my ($self) = @_;
    my ($make) = ref ($self) =~ m/^Car::(.*)/;

    print "$make $self->{name}\n";
}

sub REGISTER_TYPE {
    my ($type, $name) = @_;

    $carByType{$name} = $type;
}

package Car::BMW;

our @ISA = qw/Car/;

Car::BMW->REGISTER_TYPE('Z1');
Car::BMW->REGISTER_TYPE('Z3');

package main;

my $z1 = Car::factory(name => 'Z1');

$z1->describe();
[download]

Prints:

BMW Z1
[download]

Thanks! I made some modifications and used the idea. Mine turned out something like:

 1  package Local::Multipath;
 ...
 45 my %mpByType;
 46
 47 sub new {
 48     my ($class, %opts) = @_;
 49     return bless \%opts, $class;
 50 }
 51
 52 sub factory {
 53     my (%opts) = @_;
 54     croak ("Missing parameters!") unless exists $opts{co};
 55     my $type = _whichType;
 56     my $module = "Local::Multipath::$type";
 57     {
 58         eval "use $module";
 59     }
 60     croak "Failed to load module $module: $@\n" if $@;
 61     $mpByType{$type}->new (%opts);
 62 }
 63
 64 sub REGISTER_TYPE {
 65     my ($type) = @_;
 66     my ($name) = $type =~ m/Multipath::(.*)/;
 67     $mpByType{$name} = $type;
 68 }
[download]

...

  1 package Local::Multipath::DMMP;
  2 use strict;
  3 use warnings;
  ...
  7
  8 REGISTER_TYPE Local::Multipath::DMMP;
  ...
[download]

... somewhere else in code land ...

my $mp = Local::Multipath::factory (co => $conf);
[download]

The _whichType function returns 'DMMP' or 'Powerpath' after sniffing around for what we actually have.

It's nearly the same as what you suggested, but I didn't need the added 'type' attribute in this case, so simpler.

I could almost get away without the REGISTER_TYPE, but it has the added appeal of not having to hard code the things Multipath can handle. Just add a new module like the DMMP module shown to add new capabilities;

Thanks for the suggestion: perfect synergy.

If I want to instantiate an object, but don't know whether I have a Sedan or an SUV, can I ask the base class to figure that out for me and return the right object?

You certainly can.

Is that good practice?

This probably debatable. From a theoretical perspective, a parent class should not depend on its child classes, just the other way. Or formulated differently, you want to avoid cycles in your dependency graphs.

From a practical point of view, there often needs to be some piece of code that needs to create as-specific-as-possible objects. Why not have put it in the parent class?

An approach I found practical is to have some kind of "type registry", which is usually just a hash. On object creation, some kind of key looks into the hash, and then simply re-dispatches to new method of that type.

package Car;

has %car_by_type;

sub new {
   my ($self, %opts) = @_;
   if ($opts{name} && $car_by_type{$opts{name}}) {
      $car_by_type{$opts{name}}->new(%opts);
   }
   else {
      die "Don't know how to make a new car";
   }
}

method REGISTER_TYPE {
    my ($self, $name, $type) = @_;
    $car_by_type{$name} = $type;

}

package Car::BMW;
our @ISA = qw/Car/;
Car::BMW->REGISTER_TYPE('Z1', __PACKAGE__);
Car::BMW->REGISTER_TYPE('Z3', __PACKAGE__);

package main;
my $z1 = Car->new(name => 'Z1');
[download]

(untested)

I do appreciate your reply. You said Car->new, then had a means of figuring out it was a BMW, so I'll take that as a + vote (not literally, of course).

Got your caution about circular dependancies. This seems at least to be a limited breach of said contract. Just call Car->new once, then forevermore know that the returned object is typed according to your specifications. No harm in that? <grin>

Perhaps at least tangentially of interest: Perils of Plugins.