* 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