relax99 has asked for the wisdom of the Perl Monks concerning the following question:

Hi,

Currently, I'm writing my second application that uses Object Oriented Perl. I ran into a problem that I don't understand how to solve. I have two classes: one of them is the parent class of the other. The parent class ties to a database, and then the child class is initialized with the data from the parent class. Let's say the data in the child class changes. Then, how do I make sure the changes propagate back to the parent class and then are saved to the database? If I inherit DESTROY() method from the parent class, then it would save the changes in the child class, but they are then overwritten by DESTROY() method of the parent class with parent class' data.

Below are the relevant code samples. What's The Right Way (TM) of doing something like that?

package Control;

sub new {
    my $class = shift;
    my $self = bless {}, ref($class) || $class;

    my $cgi = CGI::Minimal->new;

    # retrieve request info
    my $session_id = $cgi->param("session_id");
    my $action = $cgi->param("action");

    my $dbh = Area::DB::connect(\$_connected) if !$_connected;
    tie %{$self}, "Tie::ODBCSession", $dbh, $session_id;

    # store action in the object
    $self->{action} = $action;

    return $self;
}

sub DESTROY {
    my $self = shift;
    
    untie %{$self};
}

package Control::Main;
@Control::Main::ISA = qw(Control);

sub new {
    my $class = shift;
    my %args = @_;
    my $self = {};

    bless $self, $class;

    # initialize with named parameters passed
    %{$self} = map { $_ => $args{$_} } keys(%args);
    
    return $self;
}

sub DESTROY {
    my $self = shift;

    # What do I do here?
}

[download]

Replies are listed 'Best First'.
Re: Inheritance and objects tied to a database
by gjb (Vicar) on Dec 20, 2002 at 12:42 UTC

    Personally I feel it would be cleaner not to tie the hash representing the object (be it parent or child), but rather to an attribute such as $self->{data}, that way it's an attribute that has to be untied rather than the "object" itself.

    Just my 2 cents, -gjb-

[reply]
[d/l]
[select]
      I agree. It does look cleaner, but how would that help?
[reply]

        Since the child is initialized with the attribute values of the parents, it "inherits" a reference to the tied variable, so parent and child share the same data. Untieing one is untieing the other.

        Hope this helps, -gjb-

[reply]
Re: Inheritance and objects tied to a database
by Tanalis (Curate) on Dec 20, 2002 at 12:34 UTC
    I could be barking up the wrong tree completely here, but isn't it possible to do something like 

    # Parent is the name of the package containing DESTROY
$self->Parent::DESTROY;

    [download]

    to call the parent class's DESTROY method over the child's?

    I'm not an OO expert, especially not with Perl, so I could be totally wrong, but that's how it works with proceedural Perl if you override, say, exit, and then need to call the core exit routine.

    Hope that helps (if it works ..)
    -- Foxcub

[reply]
[d/l]
[select]

      I tried it and, unless I made some kind of fundamental mistake in my test, it doesn't work. I think when you do something like  $self->Parent::DESTROY(); it just uses the parent's DESTROY() method with child's data. So yes, it would save the changes to the database, but they are going to be almost instantly overwritten with parent's data when the parent's DESTROY() method is executed.

      Thanks for trying to help! I'm still confused about the issue though.

[reply]
[d/l]
        I guess the alternative would be to take the save out of DESTROY, and explicitly save the data to the DB ..?

        That way, a call to, say, $self->Parent::Save would save using the child data, and you can simply bypass the save when the parent is destroyed.

        After all, if no changes are made in the child no save of the parental data should be needed anyway (if I'm reading this right).

        Just a thought ..
        -- Foxcub

[reply]
[d/l]
Re: Inheritance and objects tied to a database
by pg (Canon) on Dec 20, 2002 at 18:26 UTC
    Some of your concept about OO is wrong.

    When you change some variables in the child OBJECT, will the change be reflected in the parent OBJECT? The question is invalid.
    1. Bad news first. Some concept is really wrong here. There is no parent OBJECT at all. When you instantiate your child class, you got an OBJECT, which is an instance of your child class, which is a sub class of its parent class. There is only one OBJECT.
    2. but the good news is that, this OBJECT does contain the variables you defined in both of the child class and its parent class (The fact is simplified, but for most Perl classes, this is the case). So why do you worry?
    3. For variables (better call those attributes) you defined in the parent class/package should be visible to the child class/package, then make it part of your $self, or can be ref'd from $self.

[reply]
      Thank you! I think your answer helped me clarify my understanding of what's going on quite a bit. Now I do see where I made a conceptual error here.
[reply]
Re: Inheritance and objects tied to a database
by Anonymous Monk on Dec 20, 2002 at 12:53 UTC
    First Error: You must inherit new. Otherwise your class isn't tied. Second Error: There is no Parent in perl, it's called SUPER. Turn warnings on and you will see.
[reply]

      First: I don't mean to be rude or anything, but let's not pick on words. When we used the word "Parent" here, we meant either using SUPER or writing the specific name of the parent class, which in this particular case would be "Control": $self->Control::DESTROY(). And use strict; use warnings; are implied! If I didn't show them in my code sample, it's only for the purpose of saving space and making it more readable to allow to concentrate on the original problem and not getting side-tracked.

      Second: What's that "must" all about? Are you implying that would solve the original problem? Let's see... the parent class is tied to the database, the child class is tied to the database, child's DESTROY() method is executed first and saves changes to the database, but then parent's DESTROY() method is executed, which overwrites the changes. So, unfortunately "must" doesn't do any good here.

[reply]
[d/l]
[select]
        I think the AM was *trying* to imply that in the code snippet, you've left out the parent's new() call in the child's constructor, so the child never gets tied to the db. Of course, s/he could have just said that :)

        Maybe you could make the child DESTROY method update its parent object's data instead, so only the parent class is allowed to update the db...I suspect you're always going to have problems having multiple objects writing to a db this way unless you get a nice marshalling system going.
        Best o' luck.
[reply]

Back to Seekers of Perl Wisdom