In C++, if class Son inherits from class Father, then class Son inherits class Father’s methods and data. So it makes sense that when an object of class Son goes out of scope, the Son destructor is called to clean up the data which Son did not inherit, and then the Father destructor is called to clean up the data Son inherited from Father.

But Perl^* is different:

Perl only provides method inheritance as a built-in feature. Attribute inheritance is left up [to] the class to implement.
— perlobj

So, from the point of view of the data, there needn’t be any of the Father class in the Son class. So there may be nothing of the Father class to destroy, and no purpose in calling Father’s destructor.

^*Meaning the core Perl language, not the various OO frameworks mentioned by tobyink, below.

Hope that helps,

Update (23 Jan 2014): Added [to] to clarify the quote, and reduced the font size of the footnote.

Objects (class instances) are represented by blessed references.

When blessed reference goes out of scope (or otherwise becomes eligible for destruction), the cleanup code (only) calls a DESTROY method within the class that that reference is blessed into.

Since your instance is of class B; only B's destructor is called automatically. It is up to the writer of class B to call any base-class or delegate destructors that need to be called from B's DESTROY method.

As for the 'apparent order' or destructor calls, it all depends upon how you choose to trace them. If you output your trace messages on entrance to the destructors:

package A;
...
sub DESTROY {
    warn 'A::DESTROY'
    ...
    return;
}

package B;
...
sub DESTROY {
    warn 'B::DESTROY';
    my $self = shift;
    $self->SUPER::DESTROY;
    return;    
}
[download]

Then class Bs destructor appears to be called before class A's. But do it this way:

package A;
...
sub DESTROY {
   ...
    warn 'A::DESTROY'
    return;
}

package B;
...
sub DESTROY {
    my $self = shift;
    $self->SUPER::DESTROY;
    warn 'B::DESTROY';
    return;    
}
[download]

And it will appear to happen the other way around. So, appearances aren't everything.

The main difference between Perl and C++ in this regard is that in Perl, the destructors are called recursively, and the programmer gets to decide which order things happen in (or if at all).

In C++; destructors are called iteratively in a fixed (youngest to oldest) order.