|There's more than one way to do things|
Re2: Mmmm ... cargo cult progamming is nummy!by dragonchild (Archbishop)
|on Feb 27, 2002 at 14:24 UTC||Need Help??|
As for the confusion argument: if people get confused by seeing my $class = ref $proto || $proto they're probably not too familiar with the Perl culture.
The people complaining about this construction are familiar with "Perl culture." Heck, it's arguable that merlyn helped create some of that "Perl culture"! In my experience, the people who use this construction are the very people who are inexperienced with Perl culture. To call this part of Perl culture is to say that inefficient coding is part of Perl culture. That is something I will not accept.
You also seemed to be confused by a programming-theory concept. A copy constructor is a constructor that is invoked as an instance method and uses the values of the invoking instance as the default values for the new instance. Any values passed in to the constructor override the values of the invoking instance. Hence, the line
creates $otherDog using all the values of $thisDog, save when $someParameters would override those values. A clone() method would do the same thing.
You also state that you found a large usage of my $class = ref $proto || $proto;, but didn't find any usage of those constructors as copy constructors. You then say that we shouldn't "draw hasted conclusions"sic. I personally think that this data does support a conclusion. If a line of code is a no-op in every instance, then it shouldn't be written. It slows down the code as well as confuses all maintainers of that code. To me, the latter is much more important than the former. Whenever I see my $class = ref $proto || $proto;, I'm looking for this constructor to have use as a copy constructor. When I don't see that, my opinion of the programmer's skill drops. The programmer obviously did not understand why s/he wrote that line.
As to why that's important ... let's suppose that the line was really $class = ref $proto || $proto; (which doesn't have the my in front of $class). That raises an error under strict. If you didn't understand why the statement was there, you now have a broken module and the line that's breaking it is one you are afraid to fix! That's the problem with cargo-cult programming. It disperses code that is viewed akin to magic by those using it. "If I wave my hands and chant this verse, my code will work." I don't ever want to work with someone who's written code with that mentality. It just means that I have to clean up after them. I hate cleaning.
Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.