I don't know all the "unwritten" rules I guess.

Several are actually in the PAUSE documentation you quoted:

• Consult other people about your module before you upload.
• Avoid cutesy names.
• Add to existing modules instead of writing your own.
• Check $VERSION.

As well, it's always handy to read perlmodlib.

Personally I think Juerd is pretty on the ball with his comments. He expressed them in a pretty hard way but... *shrug* (btw, ive been on the receiving end of his comments before. youll survive ;-)

Im mostly writing about this OOorNo module. Id like to see you explain what your intentions are with this module. Ive reviewed the implementation, and CGI->self_or_default() that you mention but I still dont grok the purpose of this module, and I in fact think that its broken and dangerous. (A feeling that is compounded as I dont understand its intended use as the documentation is skimpy to say the least.)

It seems to be intended to be used for subs that are either called as methods or as subs. Problem is that the approach is particularly crude. Notice that the routines for this purpose in CGI bend over backwards to make sure the first argument is the right type before it overlooks it. Your code makes no such effort. If the first argument is an object, _irrelevent_ of its type, then it is ignored. So for instance if I used OOorNo as the basis for a CGI style tag generation routines i would have problems if I used blessed hashes for the tag attributes.

Some other holes are things like:

return(undef) unless ($mamma && ref($mamma) eq 'ARRAY');
[download]

To me both of these modules remind me of some of my own earliest Perl efforts. The thing is that most of it can be done by using other modules in better and more robust ways. I know the temptation of writing your own utility modules. You know exactly what and why the routines do everything that they do. And for your own limited use then that may be ok. But for public use you need to make sure your code is much more robust and much better documented.

Persoanlly i think you would make far better use of your time by reading the modules on CPAN, and not writing modules to go up there. After all, most of the code in these two modules is either in a perlfaq in a more robust form or in a module in a more robust form, or not done at all for very good reasons. (Personally I think that Lincoln Stein, as wonderful as he is should _never_ have written self_or_default or self_or_CGI. The code in these two routines _barely_ works, and should not be copied. For instance what happens if I pass an object of type CGIOPTIONS as the first arg to a sub that uses this routine? OVID one time wrote an analysis of all the rules that Lincoln broke in CGI. Suffice it to say that generally speaking this module is not one to copy.

Good luck, hang out read the many many nodes about the things that you are obviously interested in, bounce ideas off the monks, and refrain from CPAN'ing until you have a crowd of people here saying "I wanna get me some o dat!"

:-)

--- demerphq
my friends call me, usually because I'm late....

"This is _horrible_. If I provide a blessed array your code breaks."

Thanks, I can't believe I didn't see that. I should have used
UNIVERSAL::isa( )
It's strange that I posted something to CPLM a little while back that talked about this. Merlyn chimed in too, explaining why using this technique rather than using CORE::ref( ) was the scalable, portable, correct WTDI. (tmtowtdi).

I've poured over CGI myself. Basically, that module is a horrible mess. That's ok for someone who wants to use it, as it's not only one of the few messes that work, but one of the even fewer than work well in practice. It's very robust at what it's supposed to do, ie providing all the information a CGI script needs about its surroundings. But internally it's such a thorough mudball that I'm trying to switch to CGI::Simple wherever I have the opportunity (especially as I never use the HTML generator functions of CGI.pm). Ideally, it would get as much use as CGI and we could just as (more, even) confidently recommend it to people who write CGI scripts than we do for CGI today.

Makeshifts last the longest.

demerphq said,

Personally I think that Lincoln Stein, as wonderful as he is should _never_ have written self_or_default or self_or_CGI. The code in these two routines _barely_ works, and should not be copied.

My personal opinion of CGI.pm is that it is great! I couldn't care less if Lincoln made things harder for people to inherit from his module, because it offers a good deal of original ideas. I like the idea of allowing both OO and non-OO, especially when updating a module to a more object orriented architecture. You then allow for an object which can hold its own options, or an a module global variable, which must be parsed before another one. It allows me to do this:

# Set variables for the next group of operations.
MyMod->opt(1 => 1,
           2 => 1);
for ( 1..10 ) {
MyMod->set( $_ );
MyMod->do_op();
}
[download]

or set options for each object if the object require differant options. Just document the inflexibility of the code, and that people shouldn't try to emulate the code unless they know what they're doing and I think it's pretty fair.

. I like the idea of allowing both OO and non-OO,

So do I. The problem is that at a pedantic level the implementation is broken. CGI's more so than OOorNo, but.....

Just document the inflexibility of the code,

Neither CGI or OOorNo document the weaknesses of their approach. Reading the source is required to figure out what is wrong, and frankly in both cases Id guess that a fair amount of experience is required to spot the weaknesses.

IMO part of a computer programmers job is to think about how things can be broken. CGI makes attempts in that direction OOorNo does not. Neither are satisfactory on an abstract level.

--- demerphq
my friends call me, usually because I'm late....