in reply to Question on OO Perl

What do you mean by "this one is skipped"? The constructor returns a blessed hash ref that doesn't have the binDir key?

Can you provide a running, (preferably minimal) excerpt that demonstrates that behaviour?

BTW I'd prefer $class->SUPER::new(@_), just in case you want to pass additional variables to the super classes constructor.

Replies are listed 'Best First'.
Re^2: Question on OO Perl
by gokuraku (Monk) on Nov 19, 2007 at 13:52 UTC
    Well I could run the debugger and show the values, but this particular section is within a Test Script that runs like this:
    The main script called is - TestHarness.pl
    Which loads - SolarisTestHarness.pm that begins to set values, but loads the Super Values first.
    So it loads - UnixTestHarness.pm - which begins setting some values but it also loads - TestHarness.pm - because this is the Super of UnixTestHarness.pm
    After TestHarness.pm and UnixTestHarness.pm complete populating values it's back to SolarisTestHarness.pm - which only adds two values before it starts running, this is to include the $self->{'binDir'} value. But this one never gets set, so when a function getBinDir() is called, nothing is returned because the value is somehow skipped.
    Hope that is a little clearer, I should definitely drink more coffee before posting....

    Didn't know about new(@_), that is something I can try.

      You still haven't provided a code snippet that reproduces the problem, so it's still all guessing.

      The snippet in the root node doesn't look wrong, so the problem could be somewhere else. For example are you sure that the new method actually returns $self, and that it's being called?

      You could just add the line warn $self->{binDir}; after the assignment, and see if it produces what you expect it to.

      Then you can move it around in your code to trace the point where it seems to "magically disappear".

        Well I'm not sure what snippet would work. This is running a set of scripts (total of about 8 to run this example) that are using objects to set up the environment depending on platform and OS. I already have some warnings placed in the code, as well as print statements for debugging.

        The basic function is this:

        sub getBinDir { my $self = shift; if ( not exists $self->{'binDir'} ) { warn "Object member binDir not set"; return ""; } $self->{'binDir'} = shift if @_; print "Returning binDir.\n"; return $self->{'binDir'}; }

        It's located in the TestHarness.pm file, but called from UnixTestHarness.pm

        sub copyCtestBinaries { my $self = shift; my $binDir = $self->getBinDir(); if ( $binDir eq '' ) { warn "Could not set up C test binary area: $!\n"; print "Received " . $self->getBinDir() . " for binDir.\n"; return; } $binDir = $binDir . "\/*"; print "BinDir = $binDir.\n"; my $appBin = $self->app1() . "/bin"; print "AppDir = $appBin.\n"; `cp $binDir $appBin`; }

        With the values set up in SolarisTestHarness.pm

        sub new { my $class = shift; # Pass the command line to the base class. my $self = $class->SUPER::new(@_); # Set OS specific defaults. $self->{'binDir'} = 'bin/solaris'; bless ($self, $class); return $self; }

        One thing I did try, was to move the function to the SolarisTestHarness.pm file and set it there if its not set already. Which generated the following:
        Can't locate object method "getBinDir" via package "SolarisTestHarness" at /opt/testharness/UnixTestHarness.pm line 90.

        A reply falls below the community's threshold of quality. You may see it by logging in.