However, you may want to check out prototyped-based programming via Class::Prototyped, as illustrated in a recent column of mine.

In traditional OO, your child class inherits the behavior of the parent class, not the data of a specific parent object.

Yeah, but the de facto Perl standard of doing OO means you do inherit all the data of a specific parent object.

Abigail

Perhaps you want something like what I've posted below? It keeps a copy of the options passed to the parent constructor and passes them, along with any new options, to the child constructor. I'm not sure if it's something like this you are looking for, or if I am way off base.

update: Added an iterator to the main script to show results of child creation. In a real-world example, you'd probably want methods to access the children, rather than digging around in the package internals as I have done below.

package Parent;

use strict;
use Child;

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

    my $self = bless( {
        _opts     => \%opts, # save parent options
        _children => []      # an array of children
    }, $class);

    return $self;
}

sub new_child {
    my ($self, %opts) = @_;

    my $child = Child->new(
        %{ $self->{_opts} }, # the saved parent options
        %opts                # the new child options
    );

    # save this child inside the parent object
    push @{ $self->{_children} }, $child;

    return $child;
}

1;

package Child;

use strict;

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

    my $self = bless( { _opts => \%opts }, $class );

    return $self;
}

1;

package main;

use strict;
use Parent;

# Create the parent object. We will create child objects
# with it and save those child objects within the parent.
my $p = Parent->new( foo => 1, bar => 2 );

# Create the first child. Pass an extra option in.
my $c1 = $p->new_child( baz => 3 );

# Create a second child. Give it different options.
my $c2 = $p->new_child( qux => 4, yeah => 5 );

# Iterate through children and see which options they got.
for my $child ( @{ $p->{_children} } ) {
    while ( my ($k, $v) = each %{ $child->{_opts} } ) {
        print "$k ==> $v\n";
    }
    print "\n";
}
[download]

Wow, thanks for the lightning fast and enlightening response. This looks like what I was thinking about, but I have one more question.

Is it necessary to store the children in the parent, like what you do in the Parent package:

# save this child inside the parent object
    push @{ $self->{_children} }, $child;
[download]

Or is it enough to pass the child a reference to the %opts?

And thanks!

s-t

No, you do not need to save the children within the parent. I only did that as an example. If your project doesn't require that the parent keep track of the children it creates, then you can safely remove that section.

Or am I hopelessly off target on this whole thing?

Possibly :-) As merlyn says it looks like you're trying to inherit state rather than behaviour, which is the opposite of what most object oriented systems do.

Can you describe the problem that you're trying to solve with Parent and Child? There may be another way of attacking the problem.

Can you describe the problem that you're trying to solve with Parent and Child? There may be another way of attacking the problem.

I am starting to think that "another way" might be in order here. Here is basically what I am trying to do:

I am writing an LWP interface to an automated web publishing system. My interface already works, but is written as subroutines to which you have to pass lots of variables each time. Since my scripts are intended to be used by others, I wanted to clean them up and avoid passing around the same variables all the time. That is why I decided to do an OO rewrite.

More specifically: There is a certain amount of information that goes with the website to which the user publishes: passwords, directories, etc. Inside that site, there is a series of "journal issues" that have their own specific information, but they of course share the information pertaining to the site.

The relationship between Parent and Child in my original post was intended to describe these two different levels. I was thinking of the kind of relationship that exists, in DBI.pm, for example, between the database handle ($dbh) and the individual query objects ($sth).

So you are right about state. My Parent class is indeed intended to maintain state, while the Child class was supposed to actually do the real work. Does this mean that I should abandon an OO approach, or just quit trying inheritance?

Should my state data just be a class variable?

s-t

I am writing an LWP interface to an automated web publishing system. My interface already works, but is written as subroutines to which you have to pass lots of variables each time. Since my scripts are intended to be used by others, I wanted to clean them up and avoid passing around the same variables all the time. That is why I decided to do an OO rewrite.

Lots of state information being passed around. Sounds exactly the sort of thing that belongs in one or more objects - so I think your instincts to move to an OO model are spot on.

More specifically: There is a certain amount of information that goes with the website to which the user publishes: passwords, directories, etc. Inside that site, there is a series of "journal issues" that have their own specific information, but they of course share the information pertaining to the site.

So a the Website has multiple JournalIssues - yes?

So you are right about state. My Parent class is indeed intended to maintain state, while the Child class was supposed to actually do the real work. Does this mean that I should abandon an OO approach, or just quit trying inheritance?

I think an OO approach is the right one, but I don't think that the relationship between Websites and JournalIssues is best modelled by inheritance.

Inheritance is used for modeling is-a relations. If it doesn't make sense to say that a JournalIssue is-a Website then inheritance is probably not the right solution to pick.

Just like the $dbh and $sth objects in DBI. A statement handle isn't a kind of database handle.

Instead you might want to look at having your Website maintain a list of JournalIssue objects internally.

Without knowing more about your application its a bit difficult to talk about specifics. I'd recommend trying to migrate to your OO model in a set of smaller steps.

If you see a bunch of state that your passing to every function wrap that up in an object and pass that instead. Do that a few times and you'll probably start seeing some of the subroutines as candidate methods for that object. Let the code guide you and you'll probably see some classes fall out fairly easily.

What I would do is call SUPER::new->() (or whatever the constructor for your base class is) then manipulate the reference that comes out of that and then bless it into the child package. This is just off the top of my head but I would check here perltooc, which is class data in perl faq or here.

Thanks for all of the feedback.

I ended up following just about everybody's advice and have ended up with a solution that seems to work. I gave up on inheritance and instead gave each Child (though no longer a child, per se) à copy of the Parent objet.

I was actually surprised to see that, from the child objet, I could still call the parent methods, by doing this :

$child->{_parent_object}->method();
[download]

Thanks again

s-t