My apologies to tye. I retract my reference to tye's post. I apologize for grossly misrepresenting your post, Tye. I was thinking of a post textually near yours. Normally I recheck such stuff but I was experiencing repeated server errors and local network problems as I mentioned in that post.

I guess I'm unique in confessing: I without any real critical thought trusted what I read in the second Camel back in '96 or so. Not having any experience with OO combined with a typing system like Perl's I don't think my judgement should have been used to second guess Wall, Christiansen and Schwartz's on this.
Since it worked and no one criticized it, I never gave it much thought until I saw one of merlyn's nodes here last fall. I did use some critical thought on some other matters in the intervening period.

Incidentally, I am not fond of the term Cargo Cult. myself, I've used it in this thread to set some level or degree to my use of thoughtless and mindless imitation.

If I thought the copying in question was "mindless", would I have described it as "best practices"?

Apparently not. I'd say that following "best practices" has little to with critical thought; assessing and determining what are "best practices" does.

The most direct alternative is to have $obj->new() be interpretted as "$obj"->new() or something like

    "Class::Next=HASH(0xdeadbeef)"->new()
[download]

which is just ridiculous! I wonder how many of your classes have this problem.

None. It is ridiculous, I don't see why you bring it up.

... more reasonable ...

    sub new {
        my $class= shift(@_);
        Carp::croak "Usage: ",__PACKAGE__,"->new( ... )"
            if  ref $class;
        # ...
    }
[download]

I advocate this usage. I did not think this needed spelling out. Your sample is almost exactly what I use, first I'd croak on a bad size of @_. If reworking my earlier code I might first use carp to find the callers in the tests.

In a much more advanced treatment of Perl OO, I'd expect much more discussion of the problems with that and the reasonable alternatives to it.

I guess we are doing the advanced treatment here and now. Glad to have you join in.

If I didn't want to allow $obj->new() then I would separate my class methods from my object methods by putting the class methods in one package and having constructors create objects blessed into a different package that contains only the object methods.

Why? What does this split gain you?

But that creates quite a few other complications, especially if you want to "support" willy-nilly inheritance which the beginning Perl OO documents appear to want you to do.

I agree about the complications. I'm not sure what willy-nilly inheritance is.

It is rather funny how much ire is directed at that one line. It brings out wails about 'cloning' and yet no cloning is done in that line. You should be complaining about some other line of code that actually copies data from the old object to the new.

I am not wailing, I was trying to elucidate a point, I don't consider it a major issue but small improvements that can be idiomatic have little cost. If you read this thread it should be clear that I am not criticizing the mingling of cloning and construction.

Yes, I do see

  sub new { bless {}, ref $_[0] || $_[0]; }
[download]

as worse than

 
 sub new { croak "new takes class" if ref $_[0]; bless {}, $_[0]; }
[download]

    Can't locate object method "twirl" via package "Bar=ARRAY(0xbadd0g
+5)"
[download]

and have probably no clue what the heck went wrong.

This argument is disingenuous, you yourself have demonstrated that with simple error checking this is not necessary.

There must be some examples of what alternative I should use somewhere in one of these long threads. Someone find one so we can see it. It is certainly rare that such gets shown.

You've written it yourself here.

...I like to let the module user just mention the module name once (in a use statement) and get a customizable factory object put into a lexical variable ...

That is nice. It's not relevant to your main point. Update: Everyone should consider the chance of name conflicts when doing this.

Your use of $obj->new( "stuff") to clone or partially clone $obj, I see as very reasonable. With the implications in your example I find it extremely so. Like you I'd prefer a different name.

... in Perl OO, there is no distinction between class methods and object methods (they are both just subroutines in the same package)

Yes, I said that earlier in this thread.

so I like to make my Perl objects have the ability to be both objects and factories.

This is certainly possible, but I don't see any causal relationship to your previous clause.

being less convenient and more strict in hopes of catching mistakes earlier.

If the hopes are realized then it is more convenient.

... it is the best technique for new Perl OO programmers to use in order to prevent confusion.

Best? This is unsupported opinion. I would like to see your justification. It is good to know common idioms even if they are not optimal. But it would be better to learn better idioms also. If the finer nuances of better code are unnoticed by some, that doesn't make the code bad. Certainly (ref $obj)->new is not going to slow down a common Perler, and it presents more info than $obj->new in the simple case so I say it is better.

I suggest you get some coding standards for your project rather than trying to enforce coding standards on the rest of the Perl world

I posted my standards for comment. To say that I am trying to enforce coding standards on the rest of the Perl world is insulting, but I won't say you've gotten even yet.

Your restraint and manners are admirable. I have the opinion that my faux pas really irked you and that you're writing below your usual level. So again: Sorry.