Please don't try to read CGI.pm as an example of how to do OO properly. *shudder*
CGI.pm is a great module and it is currently the only option I can recommend for parsing of CGI forms. But I cringe when I think of someone reading its source code trying to figure out how to do OO. Trying to read CGI.pm's source code to figure out how, for example, the table() method works is challenge enough (for one thing, there is no table() method in the source code).
I have a sneaking suspicion that DBI is likewise rather dense code and not something to be read in an attempt to understand OO.
Bit::Vector is all written in C code which makes it a pretty bad example as well. Bit::Vector::Overload might be a better choice but since it makes heavy use of Bit::Vector I still can't recommend it.
The only example OO modules that pop into my head are examples of OO mistakes. For example, Data::Dumper has an awkward interface. My Win32::TieRegistry should use a separate package for the tied hash. Array::Compare needs to provide non-OO alternatives. Exporter.pm and DynaLoader.pm shouldn't be using inheritance.
But that makes sense since part of the point of a well-written module is that you don't trip over interface mistakes and don't run into bugs that prompt you to read the source code. (:
- tye (but my friends call me "Tye")In reply to (tye)Re: Perl and Objects, how do strongyou/strong resolve the two?
by tye
in thread Perl and Objects, how do you resolve the two?
by frankus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |