Why not simply use __PACKAGE__ when creating a new Perl module? - perl

Question

I wish I knew the reference or document that told me that this is the best way to create a new object in Perl:
sub new {
my $package = shift;
my $class = ref($package) || $package
This is how I've been creating objects for years but now I'm wondering why go to the trouble? With the exception of some edge cases why not simply do the following:
sub new {
shift; # get rid of the object or package name
my $class = __PACKAGE__;
Are there any issues with simply doing using __PACKAGE__ when there's no special reason to try to detect what namespace the 'new' method is being called in?

Answer 1

Inheritance
# classA.pm
package ClassA;
sub new { $pkg = ref($_[0]) || $_[0] ; bless { foo => 42 }, $pkg }
# classB.pm
package ClassB;
use parent 'ClassA';
sub foo { ... }
# main.pl
use ClassA;
use ClassB;
$B = ClassB->new();
print $B->foo();
In this example, ClassB inherits methods from ClassA, including its constructor. But we still want to identify the object as belonging to ClassB, so the constructor in ClassA must respect the name of the reference passed to its constructor.
Easier and safer than
$B = bless { ClassA->new(), "ClassB" }; # or
$B = bless { ClassB->new(), "ClassA" };
or adding a pass-though constructor in ClassB.
package ClassB;
use parent 'ClassA';
sub new { bless { ClassA::new(#_), __PACAKGE__ } }

Answer 2

The class name is already the first argument to the constructor, so why not use that? You don't need to reach for anything and if you decide that the situation is more complex than you originally envisioned, you haven't artificially caused a speed bump. This code works with or without inheritance:
sub new {
my( $class, #args ) = #_;
...
bless {...}, $class;
}
Consider with anything that you program how much you'd have to change if the code situation changed. Maybe you add a couple of extra steps that you don't immediately need, but that keeps the code flexible for those times when you realize you actually needed those cases. In your case, you actually have to do extra work to ignore the invocant argument that Perl specifically provides to tell you which class is trying to mak a new object.
For example, you create your class, it works for you and does its job well. It works so well that you share it and someone else uses it and they are mostly happy with it for awhile until they need this one little modification. They should be able to subclass your module (so, no changes to it or for you) to extend or override a method. But, your code doesn't allow that because you blessed the object in a more restrictive way that didn't add any benefit.
That first bit of code in your question is using the first argument too, but it's not really a prescription for constructors. It's doing an extra thing by allowing an already existing object create a new one. The ref extracts the blessed package name from the object and uses that for the new object.
I don't particularly like that way of creating new objects and I think the interface will likely confuse people. What should happen when you call new on an existing object? Do you clone the existing one? If so, there are better names, such as clone (Ruby uses dup). Do you get a completely fresh object? If so, why do you go through an existing object to get one completely unrelated to it?
There was a time that many examples of OO Perl showed that same sort of constructor, and it was copy and pasted into many places. But we've learned a lot since then. Maybe you have a good answer why you'd allow that, but so far I haven't heard a compelling one.