That's the problem. If the parent class defines _frobnicate but doesn't document it, you might accidentally define _frobnicate in the child class (because underscore convention!) to do something completely different, and kaboom!

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

Or worse still, you're writing a child class and carefully check that the parent class doesn't define _frobnicate; everything seems good. Then you install an upgrade of the parent class from CPAN, and it defines _frobnicate.

If the updated parent class had made frobnicate a public method then the problem would be pretty easy to track down, maybe even by just reading the Changes file. If the updated parent class had used my $_frobnicate = sub { ... }; this wouldn't be a problem to begin with.

toby döt ink

> you might accidentally define _frobnicate in the child class ... and kaboom!

for completeness, we might not get a "Subroutine _frobnicate redefined at" warning but it is possible to dynamically inspect a parent class with ->can from UNIVERSAL

So it's not that the "sub-class"-developer is completely in the dark.

It should even be possible to check this automatically.

(which is the saner approach since people don't tend to read the docs after a parent class got extended)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

ahh ... I see.

I think we have now three documentation levels to be distinguished:

• docs for the user of the module/class
• docs for the developer of subclasses
• docs for the maintainer

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}