You might be interested to know that merlyn posted a snippet to do this a couple of years ago at Create a constructor named the same as your package name!. I think his solution is cleaner, but there is some debate as to whether it's a good idea in the first place :)

I think a better argument to make is whether new is always the wisest name for a constructor. The canonical example is DBI, where the constructor is named connect. I think that design decision was a very good one.

Gah! You want to keep repeating "Some::Other::Class" and get rid of "new" ?? Of the two, the former is much more annoying than the latter. Module names need to be world-wide unique so they need to be fairly long and nearly self-explanatory. Which makes them lousy things to be repeating all over the place in your code. Especially since it is not uncommon for me to switch module names (either because a module got renamed or because I'm using a different module that provides similar functionality).

I like having names for constructors. new() is often a fine name but I often use other names. For example, Win32::TieRegistry didn't even have a 'new' method at first (it had 'Open' and 'Connect'). I also prefer (in most cases) to allow $obj->new( ... ) so that I don't have to keep specifying the configuration parameters that most classes end up having that boil down to module-user preference (and so should only have to be specified once by each module user).

So I much prefer the model of 'use' module, specifying configuration parameters, and get a factory object that you store in a variable having a nice name that use strict will tell you about mispellings of at compile time (just like use tells you about module name mispellings at compile time and unlike how Class::Name->new( ... ) doesn't tell you about mispellings at compile time).

This is especially nice since Perl's OO implementation usually makes it trivial to provide such factories by just making a global incomplete object for the class that contains the default configuration parameters and then allowing $obj->new( ... ). Then you just make Class::Name->new( ... ) turn into $globalDefaultObject->new( ... ) and you don't have to write special code for initializing default values, just simple code to copy (the configuration) parameters from one object to another.

Even nicer would be giving Perl the ability to have real references to modules (a.k.a. packages) and letting people tell strict.pm that symbolic references to a module/package should be a fatal error. This would have the same types of benefits that many already tout for avoiding symbolic references to variables. But even better is that it would allow multiple versions of the same module to be used by the same script (it would even allow custom implementations of the same module with the same version number, which is more than the complex Perl6 scheme would allow, last I looked) and would simplify custom installation of modules, which also makes development of new modules less frustrating for 'newbies'. I outlined this further at Re: $foo = "Foo::Bar"; $foo->new() works? (factories++).

One inconvenience is that Perl 5 doesn't make it easy for require and use to return these factory objects. You can almost get away with my $q= require Net::CGI; but the default return value is "1" not "Net::CGI" and even if Net::CGI is improved to return a factory, it will only do so the first time it is required. But even better than require is use, because it allows you to specify your desired configuration. A chatterbox conversation with Larry lead me to believe that Perl 6 will support my $Factory= use Class::Name( ... ), and I'm even optimistic that such could be done for Perl 5. But, for now, a good approach is something like:

use Data::Heap::Whatever 1.1 ( \my $Heap, KeepTies => 1, CompactDump =
+> 1 );
#                              ^^^^^^^^^ Factory object gets put into 
+this lexical variable
my $bestScores= $Heap->new( '>', -max => 10 );
my $worstScores= $Heap->new( '<', -max => 10 );
[download]

This allows you to get rid of all class methods, which surely makes the interface thinner.

Or you could just use aliased:

use aliased 'Long::Class::Name::For::Customer';
my $customer = Customer->new;

use aliased 'Worker::Class::With::A::Long::Name' => 'Worker';
my $worker = Worker->new;

use aliased 'Class::Name::With::Imports::For::Munger', Munger => @impo
+rt_list;
my $munger = Munger->new;
[download]

Or if you prefer lexicals:

use aliased;
my $Customer = alias 'Long::Class::Name::For::Customer';
my $customer = $Customer->new;
[download]

This works well because the module author doesn't need to provide support for it. aliased pretty much works for any OO module.

Cheers,
Ovid

New address of my CGI Course.

I was addressing module authors more than module users. That looks like a nice module for when using modules that don't already support factories [well, the last example -- the prior ones would need to be written as Munger()->new( ... ) to meet my best practices but still wouldn't meet my preference]. Note that your module wouldn't work for a module that actually did get rid of all class methods. (:

Oh, and that last example would need to be use aliased 'alias'; to meet my best practices. I suspect your module doesn't support that, so I doubt I'll be using it until that gets fixed. :)

- tye        

and I'm even optimistic that such could be done for Perl 5. But, for now, a good approach is something like:

use Data::Heap::Whatever 1.1 ( \my $Heap
[download]

That reference constructor there is a nit for me. Why should the user be required to provide it? There is no functional reason that it is needed. The import routine should get an alias to the whatever was passed in so I cant really see a reason for it.

Sorry, but I've encountered this design choice a lot (DBI does it somewhere iirc) and it always kind of irritates me as it seems to me to be so unperlish.

---
$world=~s/war/peace/g

An alternative:

use Data::Heap::Whatever 1.1 ( Factory => my $Heap, ...
[download]

But the passing of a reference has two purposes:

1. It lets us reliably distinguish between an option name and a variable being passed in to receive a factory, thus allowing the more stream-lined usage
2. It makes the fact that $Heap will be modified explicit, serving as a form of documentation

I don't have a strong preference (other than wishing use could return a factory), though.

- tye        

use Data::Heap::Whatever 1.1 ( \my $Heap, KeepTies => 1, CompactDump =
+> 1 );
#                              ^^^^^^^^^ Factory object gets put into 
+this lexical variable
my $bestScores= $Heap->new( '>', -max => 10 );
my $worstScores= $Heap->new( '<', -max => 10 );
[download]

$Heap is scoped to the implicit BEGIN block.

Thanks. Drat, I thought I'd used that before. So you need to declare the variable outside of the use statement (which is clearer and how I'd normally write such code anyway).

- tye        

One thing why I see no great benefit in this is that I often use other constructors instead of ->new, for example constructors named ->parse, ->load or ->create - removing that information from the constructor either makes an additional parameter necessary or removes the "gain".

Also, I often create objects through strings/factories, which is unwieldly/impossible with this approach as well:

my $class = "My::App::Plugin::$action";
my $handler = $class->new(...);
[download]

So the slight gain of eliminating ->new isn't worth it to me.

Obviously, this approach has issues if the last part of the package name collides with a function name in the parent package namespace, but that may be a limitation people are willing to accept or work around. So what do you think? Useful? Nuts?

I'd put it in the "nuts" category I'm afraid because of the name collision problem you pointed out :-)

<update>oops - hit submit too early</update>

Another technique for removing new would be to stop doing any initialisation of the object in the constructor - then you can do something like File::Find::Rule where you can do:

File::Find::Rule->directory->in( $directory );

# rather than
File::Find::Rule->new->directory->in( $directory );
[download]

I proposed another solution to get a "silent" constructor in my Dog $spot;. It involves merely naming the constructor MODIFY_SCALAR_ATTRIBUTES(). It almost works, but some dummy attribute must be cited for the constructor to be called,

use Some::Other::Class;

my Some::Other::Class $obj :dummy;
[download]

Without a verb, your statement "Some::Other::Class( \%options )" has no visible action although one is being performed

And heaven help the poor fool who has to maintain it when it becomes this:

my $foo = Some::Other::Class( code => sub { DoThingsWith( $_[0] ) } );
[download]

In the previously mentioned absence of a verb, someone is definitely going to think the action comes from DoThingsWith()....

But I'd be the last person in the world to discourage a Very Cool, if Quite Tricky Idea. It's cleverness personified, and I don't care what The Damian says...cleverness has a place in the world!

Put it in Acme please, so nobody I code with uses it :)

~Jeff

Maybe I'm still stuck in C++ mode, but I like 'new' - it lets me know what's happening, kind of sticks out a bit. True, it can be avoided - but is that a Good Thing? Sometimes I like a bit of redundancy, if it makes clear what's going on. Typing a few extra characters is a small price to pay for clarity, IMNSHO.

If we're talking about nuts, well... here's a weird faulty working version... :)

package a::b;
use strict;
sub a::b {
    my @l = caller(0);
    open my $f, "<", $l[1];
    my $line;
    for (0..$l[2] - 1) {
        $line = <$f>;
    }
    my $pack = $l[3];
    if (!@_ && $line =~ /$pack\->/) {
        return $pack;
    } else {
        return $pack->new(@_);
    }
}
sub new {
    print "new!!! ".join(", ",@_)."\n";
}
sub c {
    print "a::b->c()!!!! ".join(", ",@_)."\n";
}
package main;
a::b;
a::b('a');
a::b->c;
a::b->c('a');
[download]

UPDATE: use of __DATA__ substituted by opening the file itself...