All of them are right, or wrong, or perhaps only some of them, sometimes, ...

It all depends on your programming style and what you want to do with the object.

Are all your objects perfect structural clones of each other with only the internal data changing? Then go for the "define the whole structure in the new method" format.

Does the structure and content of the object depend on various external conditions which cannot be determined at creation time of the object? Then provide a new method which returns a bare bones blessed data-structure only.

These are of course the two extremes: there are many intermediary forms possible, such as using an init-method to create structure and/or provide data for the object.

Or --my favourite-- use something modern like Moose and don't sweat the details yourself.

Should it be a barebones outline of the object?

I prefer my new methods to do nothing beside creating a blessed ref and returning it.

Separating object construction and object configuration makes MI much easier.

Of course, if you believe in monsters under your bed, you probably also subscribe to the "MI is scary, don't do it!" philosophy. But this is Perl, not Java. Not only is MI possible in Perl, the *language* doesn't place more hurdles in your way than it already does with OO in general. It's just the classical way of "let's have a method that starts with nothing, return a fully configured object" that makes MI harder than it should be.

Erm, what's MI?

It's latin short-hand for the work of the devil :)

I'd go hide under the bed, but there be monsters!

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Multiple Inheritance.

And there's even a fourth way, by using a Static Factory Method as seen more commonly in Java. The best method for each case is often determined by how likely the class is to be inheritted and have it's new method overridden.

The majority of the projects I do don't rely on inheritance, so I tend to use Factories and only have a bare bones new method. But to each his own depending on the specific project.

- Miller

my $da = DataAnalyzer->new();
$da->connect_to_db->($dsn);
my $result_set = $da->run_analysis( %parameters_for_analysis );
[download]

my $da = DataAnalyzer->new( $dsn );
my $result_set = $da->run_analysis( %parameters_for_analysis );
[download]

my $result_set = DataAnalyzer->new( $dsn, \%parameters_for_analysis  )
+;
[download]

Whether or not you use an '_init' method is really just matter of style

I strongly disagree with an '_init' method just being matter of style. That's like saying "Whether or not a language has hashes is just a matter of style".

Suppose you have classes with the following new methods:

package FloorWax;
sub new {
    my $class = shift;
    bless {FW_massage(@_)}, $class;
}

package DessertTopping;
sub new {
    my $class = shift;
    bless {DT_massage(@_)}, $class;
}
[download]

And now you need to create something that's both a DessertTopping and a FloorWax, using two corner stones of object oriented programming: code reuse and encapsulation.

Sure, the start is easy:

package FloorToppingDessertWax;
our @ISA = qw[FloorWax DessertTopping];

sub new {
    my $class = shift;
[download]

But then what? Without breaking encapsulation, how do you set up the object so it's both a FloorWax, and a DessertTopping? If you call FloorWax->new you get a configured FloorWax object, without the DessertTopping attributes. And if you call DessertTopping->new, you will be missing the FloorWax attributes.

If instead, you had:

package FloorWax;
sub new {bless {}, shift}
sub init {
    my $self = shift;
    my %arg = FW_massage @_;
    @$self{keys %arg} = values %arg;
    $self
}
package DessertTopping;
sub new {bless {}, shift}
sub init {
    my $self = shift;
    my %arg = DT_massage @_;
    @$self{keys %arg} = values %arg;
    $self
}
[download]

Things would be a lot easier. You could write a derived class as:

package FloorToppingDessertWax;
our @ISA = qw[FloorWax DessertTopping];
sub new {bless {}, shift}
sub init {
    my $self = shift;
    foreach my $class (@ISA) {
        my $init = "${class}::init";
        $self->$init(@_) if $self->can($init);
    }
    $self;
}
[download]

So, I argue that having or not having an _init method isn't a matter of style. Having an init (not really an _init, as it should be called from the outside) makes your class more (re)usable.

hmmmmmm, I don't think I agree with that. For a start, you are talking about a public method 'init' instead of the private '_init' that is usually used as a sort of extension to 'new' to do the actual heavy lifting. That in itself is a choice of style isn't it?
I would also argue (again a matter of preference and style) that FloorWaxDessertTopping might be better off inheriting from a ThingsThatCanGoOnTopOfOtherThings base class if it's parents are so different.
Or of course you could use Moose and define a role CanGoOnSomething or something along those lines...

I think about such themes in this way:
Q: What goal I have?
A: To obtain new object instance in meaningful state.
Q: How to do it?
A: Start with simplest new() method and gradually add initial data structures. If it starts to be too chaotic, improve it, for instance using init() inside new(). If it, after some development, does not fit requirements well, develop other mechanism...

Awesome, thanks y'all, lots of interesting points all around.

Very helpful!