Thanks for that. It looks like good guidance for future changes/implementations. None the less, I would like to understand why perl is behaving the way that it is.

BTW, it occurs to me that a reference to sub DESTROY is being added to the namespace of the package that uses Class::Std. Thus, in my test case, the sub isn't being invoked as Class::Std::DESTROY, but rather as MyClass::DESTROY. But it's the same code and I don't see how that would make any difference to whether the warning is issued or not.

Because Class::Std starts with

package Class::Std;

our $VERSION = '0.011';
use strict;
use warnings;
use Carp;
use Scalar::Util;

use overload;
[download]

and your module doesn't! Use strict warnings and diagnostics or die

I wish it were so simple, but I don't think so. In fact, my main program and module both had use strict; and use warnings; originally, as I use them habitually. So much so that initially I had thought the warnings were produced because of them and reported a bug on Config::Std that it was incompatible with use warnings;. It was only later that I realized the warning didn't go away when I removed use strict; and use warnings; from my own code.

None the less, to test your assertion, I changed the main program to:

#!/usr/bin/perl
use strict;
use warnings;

use MyClass;

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

but still the warning was produced.

Then I changed the module to:

package MyClass;
use strict;
use warnings;

use Class::Std;

my $hash_ref = {};
bless $hash_ref, 'MyClass';

sub DEMOLISHx {
    print "demolishing...\n";
}
1;
[download]

And still the warning was produced.

So, after all, the warning wasn't produced because Class::Std uses strict and warnings and my module doesn't.

Other ideas?