in reply to Paradigm Shift - Don't use strict

In fact, merlyn refers to the above style as Cargo Cult programming. Is it a class method? Is it an instance method? Why is that there?

With all due respect to merlyn, I have encountered this post in the past and frankly was quite disappointed, neigh, shocked at what he had written. At the time I decided that as it was an old post and given that I was a newbie here it was inappropriate to criticise such a senior monk and icon of the perl community. However since then I have read various discussions about newbies not being afraid of commenting when they think they should and the fact that you bring it up here has made me change my mind:

Lets consider merlyns rational for not having a dual use new()

If you want an instance method called "new", I have no idea what it's doing. If you want to clone an object, call your instance method "clone" or "copy".

So it would appear that merlyn doesn't read the documentation of the modules he uses. The documentation should specify the exact semantics of a method, including whether it can be called in object or class context, and what it should do when it is.

Now I agree if the documentation does not explicitly state that the new() is both a class/object method it probably should only be a class method. But this is perl, which as we all know if phenomenally flexible language, where part of that flexibility allows for exactly such behaviour. In fact one could almost argue that providing such behaviour goes along with the perl philosophy. After all subroutines are allowed to know if they have been called in list or scalar context, and change their behaviour accordingly, so whats the problem if constructors do the same?

Yes, there are other prominent members of the Perl community who disagree with me on this. Ask them if they were programming in Smalltalk in 1980. {grin}

And now we see what is quite frankly one of my pet peeves: The ascribing of protocols and conventions from one language to perl. Frankly I couldnt give a toss what smalltalk users did in the 80's or what they are doing now. Nor do I care how Java does things or VB or C or C++. (Except when I use them :-) So lets provide a modern equivelent of merlyns misguided words:

And just cause it annoys me so much how about a perlish one:
Update:changed 60's to 70's as per tillys email

Which IMO is as absurd as merlyn saying Perls constructors should conform to the conventions of Smalltalk. (And yes, I know that Smalltalk was the groundbreaking OO language. Consider that ALGOL/FORTRAN/COBOL were also a groundbreaking languages from the past, have you ever heard anyone arguing that we should comply with the conventions from them?

I consider any use of this ref($proto) || $proto in new to be "cargo cult programming", and mark it off as such in the code reviews I do.

To be quite frank I lost a lot of respect for merlyn when I read his post, but this line was the whammy. (Oh and its ok that I lost a lot of respect for him over this, theres still lots of respect left :-) Anybody that says 'any use of x is cargo cult programming' without giving damn good justification for the comment, is advocating cargo cult programming. And IMO the reasons that merlyn has given in his post for not using this construct are weak, verging on ridiculous.

If I was in a class where I lost marks for doing such a thing in perl because my teacher thought that I should write my perl to reflect the conventions of another language (one that I may or may not be familiar with) I would not rate the teacher very highly, in fact I would probably demand my money back. I mean imagine the scenario, there you are using closures and a hash to dynamically generate accessors for an class, and the teacher marks you down because you haven't set them up as they do in Java! Bah! I signed on for a Perl course mate, not how to do Smalltalk/Java in Perl!


My issue here is with merlyns justification and his knee-jerk approach to the issue. It should be understood that I am not necessarily advocating the use of dual use new()s.

I usually provide dual use constructors in my objects, primarily for eas of use and brevity reasons (I dislike sprinkling classnames through my code, especially long ones :-) but I recently discovered what I consider to be a good reason to follow merlyns advice:

C++ programmers like to use the indirect syntax for creating objects, instead of using the more perlish direct syntax. But sometimes they use both:

my $obj=new CLASS($arg1,$arg2); my $obj=CLASS->new($arg1,$arg2); my $mistake=new CLASS->new($arg1,$arg2);
When they make this mistake with an object that doesnt provide for dual use constructors they will get an error, when it does they will get an object. But depending on the semantics of the constructor they may get a very different object than they thought. For instance if the new() is a plain vanilla constructor in object or class, the arguments wouldn't be passed to the second call of new() resulting in a different object. Of course the story would be different if the new() in object context was a clone method.

So the bottom line is that yes there are some minor issues with dual use constructors, but no they definately are not outright wrong, much less cargo cult programming.

Yves / DeMerphq
Have you registered your Name Space?