*{"${callpkg}::$sym"} = \&{"${pkg}::$sym"}
[download]

¹Assuming you're Lincoln Stein
²From 5.005_03 since I once disected its Exporter.pm for fun

-Blake

And CGI.pm does, in fact, work.

That said: CGI.pm is atrocious in its style and horrifying in its design sense. It should be distributed in the directory examples/bad. I would welcome a well-written alternative. Atually, I'd welcome several well-written alternatives, one for each of the current module's several problem domains.

Sigh.... So many kludges, so little time.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

Got a moment to look at:

RFC CGI.pm refactoring

CGI::Simple vs CGI.pm - Is twice as fast good enough?

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Thank ghod I don't have to do it. Nice work, and nice documentation of work, too. Now for the hard part: Politics.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

In Object Oriented Perl I show a few examples of (what I consider to be) reasonable uses of the ref($class)||$class idiom (e.g .section 4.2.1 and section 12.3.5).

Of course, this does not consistitute "cargo cult" programming because I (presumably) deliberately chose to use the technique and (presumably) know why I'm doing so.

And I guess that's the point: that there's nothing wrong with using just about any technique -- if you know what you're doing and why it's the appropriate thing to do.

For example(s):

• I rarely use strict in my modules.
• I often use a roll-my-own export mechanism, rather than Exporter.
• My code brims over with symbolic references and typeglobbing.
• I almost never write comments.
• I'm not averse to using a well-placed goto (or twenty -- e.g. Switch.pm).
• I often provide multiple interfaces to a module.

Am I cargo cult programmer? I doubt it. After all:

• I rarely use strict in my modules...because I rarely make the kinds of mistakes that use strict catches and (more importantly) because I know to turn it on when confronted with an otherwise-mysterious bug.
• I often use a roll-my-own export mechanism, rather than Exporter...because I find it much easier that way to get exactly the behaviour I need.
• My code brims over with symbolic references and typeglobbing...because that's the kind of under-the-surface program manipulation that my ideas often require.
• I almost never write comments...because, if the code itself isn't enough of a comment, then I know I probably need to rewrite it.
• I'm not averse to using a well-placed goto...because it's occasionally the very best solution to a complex control flow problem.
• I often provide multiple interfaces to a module...because I know that different people like to think -- and code -- differently, and that "intuitiveness" means eleven different things to ten different people.

What about someone else who doesn't use strict, who rolls their own exports, references symbolically, fails to comment, indulges in the occasional goto, and who multiples interfaces without necessity? Are they a cargo cult programmer? Maybe so. Or maybe not. It isn't what you do...it's why you do it.

Rules are not sacred. They're merely social mechanisms, provided to protect the inexperienced, and to streamline things for the experienced-but-working-to-an-impossible-deadline. Cargo cults are just sets of rules with sociological bases, rather than logical ones. They're all about programming the way Granddad used to program, not because I understand why Granddad did things that way, but just because Granddad did things that way...and it never did him any harm!

Is that an acceptable way to operate? Well it wouldn't be for me, but it might well be for you, or for her, or for them. And if it makes your/her/their code harder to maintain, perhaps that's a small price to pay for the valuable lesson that hardship has to offer. And perhaps it's a price the majority are happy to pay in exchange for the emotional comfort of doing things in the familar way.

Is merlyn right to disparage such coding practices? Almost certainly, since that's what he's being paid to do. Does that condemnation translate to a universal proscription? Almost certainly not (nor do I think merlyn thinks it does).

The trouble is, by just looking at the code (absent the coder) there's no way to tell whether one is seeing the results of superstition or satori. But that's the essential issue.

As the Jargon File illustrates in its Zen-like appendix:

A novice was trying to fix a broken Lisp machine by turning the power off and on.

Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."

Knight turned the machine off and on.

The machine worked.

"What" is not important. Only "why" is important.

Just a few comments.

First of all I agree with you on the importance of making your own mind up. I have made similar points in the past, and on several occasions managed to irritate people by refusing to accept the received wisdom. But I think I learn better for it.

That said, there are a few points about your own behaviour that I would like to point out.

• I use strict fairly religiously. While you may not make the mistakes it catches, it catches a good fraction of my typos. Also I note that while you don't use strict, you get most of the benefits (and more!) from the test suites you write. Contrary to appearances, you do attempt sanity and caution.
• Roll your own import or not, decisions, decisions. I have written my own imports before, and most of the time I don't. The rule of thumb that I use is, "If what I want is achievable from the basic Exporter, I use that just so that my semantics will match that. If they are totally different, then I won't. Consistency is good. If I am going to be inconsistent, I have to have an opposing good reason." Generally speaking the more "interesting" the code is, the more likely it is to need custom semantics. The vast majority of code does not.
• I doubt that many knowledgable people would disagree with the uses of typeglobs and symbolic references that I have seen you use. However when you write more routine programs, I suspect you use fewer typeglobs and symbolic references.
• My commenting rules are at Re (tilly) 4 (disagree): Another commenting question,. If you count documentation as commenting (which I am inclined to), then you do indeed have verbose comments.
• I think the key-word about goto is well-placed. Few people know how to place them, and I would prefer to tell people never to use them than to have them try to figure out how to use them well. (An incidental note. Your goto in Switch also uncovered interesting bugs in the development release of Perl...)
• Polymorphism is the one issue I disagree with you on. Sure, 5 people may find 20 ways of thinking about the same problem. But if they are going to work closely together, it is important that they manage to agree on one or two ways of cooperating. Furthermore many of what I consider the worst design mistakes in good modules are attempts to overload functions with every possible behaviour. Take, for instance, CGI's param method. As I pointed out at Re (tilly) 2: form parsing, the overloading is extreme enough that even good programmers will make mistakes and omissions due to forgetting parts of the interface and therefore passing through data that may be misinterpreted as metadata.

  Yes, people find different things intuitive. Yes, people have a native capacity to handle ambiguity. Yes, as long as you stay within the limits of what people can handle, using that native ability is good. Perl has done this very well. But people's intuition is generally flexible enough to learn how your code works, and people ability to handle ambiguity does seem to have a hard upper limit. OK, possibly you don't have an upper limit. But I do, and you manage to exceed it on a fairly regular basis...

Which brings me to my biggest single comment. The average business has a huge concern known as, "What do we do if ___ gets hit by a bus tomorrow?" This is irritating for any decent programmer, we don't want to feel replacable. (Though a tip for bystanders, make yourself replacable and they are freer to put you into new, more interesting, roles.) Well you are not currently coding for a company that can ask that question, but for the sake of Perl, I hope you look both ways before you cross the street...

Contrary to appearances, you do attempt sanity and caution.

Well..."caution" at least. ;-)

...when you write more routine programs, I suspect you use fewer typeglobs and symbolic references.

Probably so. Though I suspect that, even in those cases, I'm more partial to typeglobbing a closure than most folks would be.

If you count documentation as commenting...then you do indeed have verbose comments.

Hmmm. Not sure that counts in the sense I meant. I rarely document how the code works.

Polymorphism is the one issue I disagree with you on.

Well, thank goodness we differ somewhere! I think the point is that, unlike a member of a project coding team, I write code that (I hope) will be used by thousands of people around the world. That promotes TMTOWTDI to a prime design criterion and makes it essential to provide a range of interfaces that cater to a vast diversity of coding prejudices styles.

for the sake of Perl, I hope you look both ways before you cross the street...

Yes. I do try to keep myself available to support what I've contributed. ;-)

Though, as my count of CPAN modules climbs towards the 30's (by the end of this year), it's becoming increasing difficult to maintain them all in a timely fashion. ;-(

And things will probably get even worse next year. YAS is about to announce a funding drive to extend my Year For Perl into 2002 (and to sponsor another one or two Perl Serfs as well!) But, with so many Perl people hurting financially in the tech downturn, I'm concerned that indentured servants are a luxury the Perl community can no longer afford.

So many people were so very generous in funding the work I've done this year, and I hope they felt that their contributions were well spent. But even if they do, that doesn't mean they'll still be in a position to extend that generosity this time round. Corporate donations may take up some of the short-fall, but I'm readying myself to have to cut back on my Perl work, in order to earn a living in 2002.

Of course, I may be completely mistaken about that, and we'll raise the money as easily as we did last year. I hope that's the case. But even then, things will still get worse: I'll continue to churn out new modules at about the same rate, and therefore have to dice my maintenance timeslices even more thinly. ;-)

tilly wrote:

I think the key-word about goto is well-placed.

Just out of curiosity, what do you consider well-placed? The only time I have ever used goto is to subvert the call stack. And I did that once.

You've mentioned before that goto has uses. Other than this Perl-specific reason, what else would you use it for?

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

They're actually the opposite of a cargo cultist, even if the visible symptoms are identical. ... It isn't what you do...it's why you do it. ... "What" is not important. Only "why" is important.
I'll take the antithesis to that. If I'm given a body of code to incorporate into something else, or to extend because the requirements changed, or otherwise to maintain, and I see a "mess" that is fragile and hard to change, than the original author was either very smart or had a large monkey multiplier factor. Do I care which? NO! I only see the result, that the code is hard to maintain.

In anything other than your own throw-away program, the "visible symptoms" is the only part that matters. Everything else is just cold dead history.

—John
(still making you challange your assumptions)

You missed the point.

The "symptoms" that TheDamian talked about are checklists of specific programming practices people are told to avoid. If you know what you are doing and why, you can use most of them but avoid the problems which make it simpler to tell people not to use them. The resulting code can be both good and maintainable, but will cause people who only know the checklists to freak out because it violates their checklists. TheDamian is infamous for writing code like that.

It is like swimming. If you have had any swimming lessons, one of the first things they drill into you is to not get anywhere near a drowning person in the water because you will die. The reason is that a drowning person is several times stronger than normal, and their only desire is to climb on top of you and stand on your head. You simply are not a good enough swimmer to handle that treatment. Nobody is.

Yet lifeguards go after drowning people in the water all the time. Isn't that stupid? No, because lifeguards know the danger perfectly well and understand how to avoid it. (Always approach from behind, stay in place holding the person's head up until they are calm, the instant you get into trouble - dive!)

Yes, it is dangerous. Yes, it is what everyone is told from day one not to do. But if you know what you are doing, it sometimes is exactly what needs to happen.

The real lesson is to be extremely careful when you are stepping outside the boundaries of "safe" programming :)

In the end, if it does the job, and does it well, then is it really such a bad thing? It's the author who is in general going to pay the price, in more maintenance, but that is their business. :)

                - Ant
                - Some of my best work - (1 2 3)

<rant>
[download]

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:

Yes there are prominent members of the perl community who do not think it is appropriate to use hungarian notation in their code, but ask them if they programmed Visual Basic in the 90's

Yes there are prominent members of the perl community who think it is appropriate to utilize wantarray and have their subs/methods be context aware, but ask them if they programmed C in the 70's

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!

OTOH:

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);
[download]

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.

</rant>
[download]

I disagree that this is just a protocol or convention from another language. There is a lot more to this issue.

The heart of this question is what your model of OO programming is. The ref trick makes Perl halfway towards being prototype based, but not really. Avoiding it allows you to have a model closer to Smalltalk's, which works much better in Perl. Given that I prefer Smalltalk's model, I am inclined towards merlyn's position. But given that the ref trick can't make the prototype approach work, I think that he is objectively right.

(Those who don't know what I am talking about when I talk about prototypes should read the explanation I gave at A Cat's eye view of OO.)

If you want to take a prototype approach in Perl, you can. Do it with BikeNomad's Class::Prototyped and have it work right. Don't do it with a half-way hack that allows you to maintain a bad mental model of your code that won't really work if you push it.

Furthermore merlyn's accusation that it is typically cargo-cult programming is definitely on target. Take 10 random people who regularly use the ref meme in their constructors. Of them at least 8 have never given any serious thought to the question of why they would want to write code that way. They have no clear thoughts on it at all. They have just seen the construct, use it because they have seen it, but they have no strong thoughts on what the reason is. That is exactly what cargo-cult programming is. The blind repetition of programming patterns that you have not thought about and do not understand.

And about the two other examples you gave. Steve McConnell was circumspect about saying how bad Hungarian Notation is in his classic Code Complete, but what he said there about why it is bad is exactly correct. And it was correct coming from someone who had (among other things) done VB programming for Microsoft in the 90's. Secondly nobody programmed in C in the 1960's. It wasn't invented until the 70's. Even if it were, the use of context in Perl is something a C programmer should have no opinion on since the concept doesn't exist in C. By contrast the use of objects in Perl is something which a user of another OO language reasonably can have opinions on in Perl because it exists both places. Their opinions might be wrong for Perl, but they at least have an experience base which is somewhat relevant.

"Cargo cult" programming is evil only if it's a lifetime pattern. As a part of larval stage, it's entirely normal. Human beings learn, in part, by imitating what they don't understand ... yet.

For further information, see any human child.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

Tilly perhaps ive missed your point, but you seem to be doing the same thing as merlyn. You are trying to apply OO models from various languages to Perl. OO is a simple idea: the strong association or binding of procedures with the data that they manipulate. Everything else in OO is an extension of this simple concept. Now many languages embraced this idea and as mathematicians (think i)and computer science types often do extended the idea to its logical limits, or beyond in some cases, to see what the implications, pros cons etc of such systems.

But these ideas (prototypes, inheritance, polymorhism, overloading....) are just additional concepts that have been added (or not depending on the language) because of the interests, predilictions and whathaveyou of the various authors and users of the various languages. The fact that they are often useful or desirable features of a language does not mean that they are necessary, much less right.

Im happy that you prefer smalltalks OO model, and even happier that perl provides what is necessary to emulate it. But not because I like the smalltalk model but because I like the perl model, where I can do all kinds of things, only a few of which are considered to be standard OO techniques.

Now as I said, I have come to agree with merlyns point, but not for any of the reasons he provided (which were, to be blunt, crap). You said: The blind repetition of programming patterns that you have not thought about and do not understand. Well Im sorry but to me that is exaclty what merlyns statement about marking people down whenever he saw the construct is. The blind application of a rule of thumb without trying to understand why it was done. For instance I have written a number of GA implementations in perl (unpublished sofar). Now I have a class GA::Entity in my model. This class is used to represent a solution in the GA. When I call GA::Entity->new() it returns a randomly generated solution. When I call $ga_entity->new() it produces a randomly mutated version of $ga_entity, and when I call $ga_entity->new($other_ga_entity) it returns a cross of the two. I thought long and hard if I wanted this type of behaviour and experimented with a number of alternatives before deciding I was happy with this approach. But of course merlyn would mark me down bigtime without considering why I had done it, and what my reasons were. And that my friend is plain and simple Cargo Cult Programming.

Now, Ill grant that if merlyn had said something like "Well, generally I dont think this is a good idea. If I saw this in a code review I would want to see good justification for doing it, and a healthy amount of documentation to explain what is going on" or something to that effect then my attitude would be very different. Also I will grant that if the users of this construct are as you allege unaware of the issues related to it, then indeed it is cargo cult programming as well, but this doesnt change the fact that merlyns comments are too.

I think you might want to reread my sarcastic comment about hungarian. I was trying to come up with the equivelent of a perl guru advocating the use of hungarian in perl.

As for the C/Context point, I dont agree. To me there is little or no difference between someone who has experienced a (different) concept or not experienced the concept at all in a given langauge demanding that a second language behave the same way. That quite possibly is why they are different languages.

Your last sentence is to me the key here, Their opinions might be wrong for Perl, but they at least have an experience base which is somewhat relevant, yes their opinions are relevant but not necessarily correct. And that is exactly what I think of merlyns post. Relevent and wrong.

Yves / DeMerphq
--
Have you registered your Name Space?

tilly: Furthermore merlyn's accusation that it is typically cargo-cult programming is definitely on target. Take 10 random people who regularly use the ref meme in their constructors. Of them at least 8 have never given any serious thought to the question of why they would want to write code that way.

I know what it does, I know when I would use it, but I honestly can't remember when I've actually utilized a prototype, yet I continue to put the 'ref($proto) || $proto' stuff in my code (I think I may have actually used it once but I'm not sure). In a code review with a 'perl master' (not merlyn) at the conference I pointed out that I'm not sure if its all that useful but he assured me that it was fine. I figure that it has become such an idiomatic perl thing that if you don't do it that way, you take the chance of disappointing someone down the line who might want to utilize it (yeah, it's a weak excuse).

merlyn: 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.

Hah! beat ya to it. Though I continue to use it, I mark myself off first (and this is what I had in the 'code review'):

sub new {
    # Do the cargo cult OO construction thing
    my $proto = shift;
    my $class = ref($proto) || $proto;
...
[download]

The heart of this question is what your model of OO programming is.

Is it? I'd say that for me, this boils down to the following considerations:

1. Do you want to or need to permit someone to call either $obj->new() or (ref $obj)->new()? (Typically, no. Consequently, on those occassions where I've done this I've got to admit it has been cargo-cult. But now that I'm aware of this, I come to the next question...)
2. Even if you don't need this, are you going to permit this anyway? Are you going to allow someone else to do this with your module, and to do this as a direct object method, without calling ref($obj)? (And here, my answer is "Why not -- how could it hurt?")
3. If you say 'yes' to either of the above, are you confused by the name of the method new(), so that you don't know if it clones or not? And my answer is, "No! If I wanted the method to clone, I'd've named it clone() and not new()!"

In short, for me it's a matter of interface preferences, and how strict/permissive I want to be with that. The philosophy of it all only comes down to the simple question of whether it makes sense for new() to ever behave as clone(). To me it doesn't; this may be because I only really learned OO via Perl (and some Java) so I'm not influenced by Smalltalk or other languages.

-- Frag.
--
"Just remember what ol' Jack Burton does when the earth quakes, the poison arrows fall from the sky, and the pillars of Heaven shake. Yeah, Jack Burton just looks that big old storm right in the eye and says, "Give me your best shot. I can take it."

Confucius say,

Do what is right: Do not adhere to dogma.

On a more serious note, my old english teacher used to say that once you know all the rules, you may freely break all of them. I use strict; on a religious basis due to the fact that I'm only a fair-ish coder but on the day that I feel that I have a very good reason to break the rules, I will and with absolute conviction that I am on the righteous path.

"Without evil there can be no good, so it must be good to be evil sometimes.
--Satan, South Park: Bigger, Longer, Uncut.

Perhaps version 3.0 addresses some of the issues, although he still doesn't use strict; according to a quick glance of the code.

----Asim, known to some as Woodrow.

I feel you, man, er, as it were.

My philosophy is that there are alot of areas where my own expertise is well below that of others; leveraging those others' skills effectively permits me to focus on my own goals in the short term (which pays the bills). In the long term, osmosis is unavoidable anyway.

The upshot (for me), is that CGI.pm (like XS and many other facilities that come with perl) are black box tools which do what I need for very little cost, and one day (when a get a round TUIT), perhaps I'll dissect them to understand more.

Why rush the inevitable?

dmm

BTW, one point in CGI.pm's favor: it doesn't pollute your namespace without being told to.