But what makes you say that this usage is almost always an error?
In the original code, $class went entirely unused. All of the shenanigans to figure out whether the invocant is a reference are useless.
The design problem with this technique is that it allows you to write:
my $object = Class->new();
my $otherobj = $object->new();
What relationship should $otherobj have with $object? Does it have any? It's easy to expect a prototypal relationship between the two, or one where the former's instance data somehow sets the latter's, but there's almost never any code in the copy-and-paste copy constructor to set this.
Why create an interface that does nothing?
Worst yet, consider what happens if someone invokes the constructor like this: o
my $object = Class::new( {} );
I know that's unlikely, but the copy constructor technique will silently create an object blessed into a package called HASH. Without the copy constructor technique, Perl will happily throw an exception about attempting to bless into a reference. This technique silences useful error messages for no good reason.
As far as I can tell, the only reason this code persists is because someone put it in the documentation as an example of a cool technique, and people started thinking it was necessary because the documentation explained Perl 5 objects as crazy black boxes that require a lot of arcana. |