Exactly! But you would not have to dredge if the author had written Packet_Foreign->new. This is the root of the objection.

(ref $obj)->new
The code tells that you need to determine the type of $obj to figure out how the call to new is resolved.

Obj->new
The code tells you where to start to resolve the call to new. This can be of great benefit to the reader in some situations.

$obj->new
The code obscures the author's intent. Could he have written Obj->new but didn't just because of mindless imitation? Could he have written (ref $obj)->new but didn't just because of mindless imitation?

I give you rir's observation: When the code is bad, the documentation is worse. So I find your statements to rely on the documentation unconvincing. If truth and beauty don't exist in the code, I won't count on finding them in the documentation.

I am sorry that I unable to make my point to you. Last fall when I first read merlin's criticism of this idiom as Cargo Cultism, I was resistent. My first thoughts: it is no big deal; it's just a little convenience; it is in the Camel; it has never bothered me; and merlyn is being exceedingly fussy.

But since I really had adopted the usage without critical thought. And since I had, still have, no good argument against high standards, especially where it resolves to an idiom, i.e. think once -- type many. I did consider and quickly found fault with the idiom. My reason to deprecate the idiom is different from merlyn's and, I think, a much stronger one.

I won't write $class = ref $class || $class because it supports the thoughtless use of $obj->new which can be obscure.

There are other views: tilly's posts A Cat's eye view of OO and Re (tilly) 2: Paradigm Shift - Dual Use Constructors and their associated threads. Also Re: (Ovid - minor code nits) Re: Adding autoloaded methods to symbol table with using strict refs.

Update: True confession time: When first I adopted the dual method trick its cuteness appealed to me. So I used it unnecessarily.
Fixed minor typos.

Howdy!

...but writing Packet_Foreign->new means that I have a priori knowledge that I always need a Packet_Foreign thingy. That is not the situation in the scenario at hand.

In the scenario under consideration, one is handed an object and needs another of the same class. Either one takes ref($obj) before calling new or one does it *in* new. The scenario does not admit a choice. One *could* pass the value to new as an argument, but that is just another variation (that may be productive) that I'm going to gloss over for now.

The code obscures the author's intent. Could he have written Obj->new but didn't just because of mindless imitation? Could he have written (ref $obj)->new but didn't just because of mindless imitation?

I give you rir's observation: When the code is bad, the documentation is worse. So I find your statements to rely on the documentation unconvincing. If truth and beauty don't exist in the code, I won't count on finding them in the documentation.

It is not reasonable to attribute use of the offending idiom to "mindless imitation". That steers the discourse toward a discussion of the discussor and away from the subject. The followup observation continues that unpleasant course.

I do not blindly accept that the idiom is, per se, a Bad Thing(tm). I do accept that it has the potential to create confusion. I do claim that proper documentation and the use of it by the programmer should mitigate that confusion. It is not that you are "unable to make your point to [me]"; it is that I do not blindly accept it as the One Truth.

More generally, what do you expect to happen if you call a class method as an object method? As developer of the module? As user of the module?

I see this whole issue as having a number of shades of gray, not just black and white.

yours,
Michael

Update: Removed unfounded, baseless slur on tye. My apologies to tye. I was thinking of a post textually near his, I would have rechecked the reference except for the server & network problems mentioned in my post.
I won't mention the author I meant to refer to because, on review, he didn't not really confess, he just strongly implied that he had rather thoughtless imitated this construct. I am unique, I am the only known confessed and repentant former thoughtless user of $class = ref $class || $class

writing Packet_Foreign->new means that I have a priori knowledge that I always need a Packet_Foreign thingy. That is not the situation in the scenario at hand.

That was the scenario with the code I posted. We seem to keep referring to different scenarios and aspects of the issue. I am focused on the unclear use of $obj->new in place of Obj->new and that that muddies the meaning of $obj->new in most situations. You seem to point to $obj->new as an equivalent to (ref $obj)-new.

All I've got out of your arguments is that you wish to save five keystrokes per call, ()ref, and spend more text in the documentation of the code instead. That seems ridiculous.

It is not reasonable to attribute use of the offending idiom to "mindless imitation".

It is reasonable to consider it as a possibility. I am of fair intelligence and have admitted to repeatedly doing so myself. If you followed the links I gave, you will see others confessing also. tye comes to mind offhand. Copying the practices given by Wall, Christiansen and Schwartz is not a bad approach to learning Perl, but it is rote learning and so the label mindless imitation may apply. The writer of $obj->new does not see any reason to distinguish his code from the code of Cargo Cultists, so the reader won't know if it is Cargo Cult Code without doing extra work. The writer of ref $class || $class abets this practice.

You may have specific intent regarding the meaning of $obj->new but the poor use of the idiom means I have to be clued in by you to know your specific usage pattern and then track who is writing a piece of code. Given that you, and I, are doing so poorly in making our positions clear to one another just reinforces my feeling that the code should be as clear and informative as possible.

In the absence of compelling reasons I'll choose to avoid creating confusion over creating it and then attempting to mitigate the confusion.

I see colors and shades of grey also. Here I find no blending of shades. I have given a clear reason to habitually avoid $obj->new. You have just stated or referenced personal preferences, I don't find a reason for your preference in your posts.

Here in two lines of code the problem can be seen.

    $obj->new;         # Perhaps Obj->new could have been written

    $obj->method;      # method is wrong, what class do
                       # we start looking in to fix it?
[download]

More generally, what do you expect to happen if you call a class method as an object method?

This very discussion demonstrates that this is not a valid question for Perl. Perl has functions and methods. I think of methods being called with a first argument that specifies the class of the method and may have other uses in the method. Perl makes no meaningful distinction between class and instance methods, it is just a bit of syntax. (ref $obj)->routine( $obj) and $obj->routine contain pass the same info.

As developer of the module?

In this discussion I have been more in the role of maintainer/evolutionary expander of the client code using the classes containing the new.

As user of the module?

I hope that all the arguments are checked for validity as possible. The first argument of method just happens to set on the other side of a method's name.

I don't see your questions as relevant to the issue at hand. For me it is about clarity, as in locality of information, not about following the object-orientation style of Smalltalk or Self or C++ or ...

It is interesting that our minds find differing aspects of this discussion as being worthy of expansion. My thoughts run toward variations of
How to treat comments when reading or reviewing code?

Sorry -- Would have got back sooner but for network and server problems.