Erm . . . blech. Sounds almost like you're grasping at the Abstract Factory pattern, but not quite. You need to give more detail why the superclass needs to know how to create instances of descendants and then someone might catch what you're trying to do.

Two things come to mind. You could either add a method to Class to extract the original args:

my $obj = Class->new(...your args...);
my $subobj = Class::SubClass->new($obj->original_args);
[download]

my $obj = Class->new(...your args...);
my $subobj = Class::SubClass->clone_from_parent($obj);

package Class::SubClass;
...
sub clone_from_parent {
  my $class = shift;
  my $obj = shift;
  my %args;
  ...set up %args by calling methods on $obj to get info...
  return __PACKAGE__->new(\%args);
}
[download]

my $subobj = $obj->subclass->new();
[download]

my $subobj = $obj->subclass();
# or, better, my $subobj = $obj->subclass_clone();
[download]

my $subobj = $obj->clone_into('Class::SubClass');
# ...
sub clone_into {
   my ($self, $subclass) = @_;
   return $subclass->new(%$self);
}
[download]

my $subobj = Class::SubClass->new(%$obj);
[download]

my $subobj = Class::SubClass->clone_from($obj);
# ...
sub clone_from {
   my ($package, $base) = @_;
   return $package->new(%$base);
}
[download]

In answer to some of the questions...

Both need to use the same authentication mechanism, supplied through 4 arguments. And because of state issues, the authentication state needs to be shared across all transactions. Parent object is authentication + global attribute maniputation, sub classes are manipulation of specific items - in this instance contacts, identities and messages.

My current solution is indeed:

my $subobj = $obj->subclass;
[download]

But to me, that doesn't intuitively say I'm creating a new subclass object.

How many years is it 'til Perl 6 again? ;-)

Isn't this more of a has-a, rather than is-a? The name of the superclass might give a clue here.

For example: If it is "Credentials", then I would say that a Message has Credentials, rather than a Message is-a Credential.

If the different actions are related to each other and can benefit from having a common base class, it might make sense to have an abstract base class which has their shared code/interface etc. But that needn't be the same as your Credentials class.

It sounds like you're using inheritance to share something that should be in a seperate object anyway. Maybe you just want a singleton authentication object?
"What should it profit a man, if he should win a flame war, yet lose his cool?"

But to me, that doesn't intuitively say I'm creating a new subclass object.

That's why I was suggesting to rename the method to something more readable, like subclass_clone(). Anyway, I agree with Joost about the fact that the authentication stuff should probably reside in an object by its own, whose services are used by your specific manipulation classes.

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.

package ClassFactory;

sub new {
  my ($class,%auth_vars) = @_;
  return bless \%auth_vars,$class;
}

sub create {
  my ($self,$class) = @_;
  return $class->new(%$self);
}
[download]

my $factory = Class::Factory->new( auth vars );

my $obj = $factory->create("Class");
my $subobj = $factory->create("Class::SubClass");
[download]

In Class, I need:

sub subclass {
    my $self = shift;
    return Class::SubClass->new(%{$self});
}
[download]

Interesting suggestion - but that just feels wrong to me. One class to one file - otherwise debugging becomes bizarre if there's an error. Imagine the confusion parsing X.pm looking for a method that's declared in X::Y.pm uder a package X declaration!

No more wrong than having a method in X return a new X::Y object. So long as you stick to a consistent way to do your factory classes, I don't see a problem.