However, that doesn't mean that as the designer of a class, you can't provide the proper instructions to prevent an error when someone ELSE calls new on an object they got from your class, be it intentional or otherwise.

Personally, I consider the following two statements to be equally as ridiculous:

Don't use ref($proto) because users of your module/class should never call a constructor on an instance.

Don't check to make sure open() succeeded because a user should always make sure they're running your program with the proper permissions to open a file.

Either way, you're depending on someone else not to break your code, and that can't be good.

" I've read that post, and that's why I said I would like to hear merlyn's thoughts."

Um, those are merlyn's thoughts. ;) Did you mean 'my' thoughts? Let's open that can of worms then. :D

At this point, the whole matter is strictly opinion. The way i see it, if someone uses one of my modules incorrectly, they didn't read the POD. That is how you provide proper instruction on how to use a class. If i want them to be able to clone a class, i will provide a clone() method, and more importantly, i will provide POD that shows them how to instantiate and, if applicable, clone my objects.

And i do not agree with your two statements being equal. The main reason is because you have two distinct audiences. Someone who just uses a program is not required to have any knowledge of the language, but someone who programs against that language better have knowledge. Further more, someone who accesses the constructor on an instantiated object clearly does not know what they are doing. Unless we are talking about a factory [method] pattern, the constructor should be class method, not an instance method. Try doing this in Java ...

class Foo {
   public static void main(String args[]) {
      Bar bar = new Bar(42);
      System.out.println(bar.foo);
      
      Bar baz = bar.Bar(2112);
      System.out.println(baz.foo);
   }

}
class Bar {
   public int foo;
   public Bar(int foo) {
      this.foo = foo;
   }
}
[download]

Does not work. Try Python:

class Bar:
   def __init__(self, foo):
      self.foo = foo 

bar = Bar(42)
print bar.foo

baz = bar.__init__(2112)
print baz.foo
[download]

Does not work. Ruby?

class Bar
   def kind=(f)
      @foo = f
   end
   def kind
      @foo
   end
end

bar = Bar.new
bar.kind = 42
print bar.kind

baz = bar.new
baz.kind = 2112
print baz.kind
[download]

Does not work. Why? Because in all of these languages, the constructor is built-in. Perl's 'constructor' is not. You should not be able to call a built-in constructor as an instance method. This is one of the reasons why i do not like to teach OO with Perl, but it also one of the reasons why i love to program OO with Perl. Correct me if am wrong, but i believe that Perl6 is going to provide a built-in constructor, called new:

class User;
my ($id, $name, $email);
# look ma, no new!!!

package main;
my $u = User.new('abw', 'Andy Wardley', 'abw@kfs.org');
[download]

So, you do what you want. That is what Perl5 is all about. As long as you know why you are doing what you are doing, all is well. But i still think trying to prevent someone from "incorrectly" using my Perl class is just plain silly. However, if you are really paranoid about such things, try this instead:

package foo;
use strict;
use Carp;

sub new {
   my ($class,$id) = @_;
   croak "can't call new as instance method" if ref($class);
   my $self = {
      id => $id || 42,
   };
   return bless $self,$class;
}
[download]

Better to deny them than deceive them. ;)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Except that open can fail as a result of all kinds of things not under the control of the program(mer). Calling a constructor in a way that is not documented in the API for a module... well, if it works the way you expected it to, that's an undocumented feature. If it works, but not quite the way you wanted it to, that's a bug (in the mind of the programmer, anyway). If it just plain doesn't work, that's what one expects having read the documentation.

Personally, I'd go with the last of these. If your constructor contains a bit of unexpected magic, you may as well document it. And if you want to allow for $instance->new(), you'll have to painstakingly document whether this creates a new "empty" object, or whether it creates a copy of the instance it was called on. FWIW, I think of "new" as a class method no matter what, so to my mind providing a way to use new from an instance is just muddying the water.

Notes on reply: my point is that you will need to document this behavior, otherwise there is no reason to include it. And I have no idea what this adds to the module or how it helps programmers. It seems only to add a layer of indirection, which Perl OO already has enough of (imho-- and hopefully this will improve in Perl 6).

If it works, but not quite the way you wanted it to, that's a bug (in the mind of the programmer, anyway).

Well, if it's not documented to work the programmer can't really expect anything from it. I don't see how that can be considered a bug if you can't expect it to work in any way at all.

And if you want to allow for $instance->new(), you'll have to painstakingly document whether this creates a new "empty" object, or whether it creates a copy of the instance it was called on.

How painstakingly is "Doing $obj->new is the same as doing ref($obj)->new"?

-Anomo