* Sean M. Burke ([EMAIL PROTECTED]) [030221 01:20]: > At 2/19/2003 01:46 PM +0100, Mark Overmeer wrote: > >[...]On this moment, I am owner of seven CPAN modules. The largest is > >Mail::Box, which has about 90 packages, each describing one class: it is > >object-oriented Perl. > >[...]Conclusion: POD is not sufficient to produce documentation for OO > >programs. > > What you say is undermined by one word: "90". > NINETY! > > One of the surprising things about OOP as practiced in Perl land is that it > you can typically do it perfectly well without deep or sprawling class > hierarchies.
Inheritance hierarchies is not a programming language dependent problem, but an programming style issue. Many Perl programmers have very little OO experience, and therefore think that simply using an @ISA turns an imparitive program into an OO version. You may think that 5 levels is too much, but it is not: it is the best way to avoid coding things double, and is not slow either, because of the method cache. Each level in the hierarchy has more than 5 (often complex) methods, so has its right of existence. > While I want Pod to be as flexible as possible while still achieving its > goals, the problem you point out is not very compelling, at least not as > you've described it. > I am always on the lookout for a solution to this > problem; but for the time being, think of it as an inadvertent tax on ISA > hierarchy deepness. I do not understand what "this problem" is in your case, and I see no "inadvertent tax on ISA hierarchy deepness". What do you mean? Well, only the "see you a use for yourself" question of my e-mail is answered. Apparently not for your code. What remains is that I see a good use for myself (and many other OO modules). So the remaining questions I ask to the members of this POD discussion group remain: 2) If I extend my concept into a usable module, would the "community" accept it as alternative to plain POD? 3) What name-space should my module take? -- MarkOv %-] ------------------------------------------------------------------------ drs Mark A.C.J. Overmeer MARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net