Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re: Documenting non-public OO components

by Zaxo (Archbishop)
on Sep 06, 2005 at 15:59 UTC ( #489575=note: print w/replies, xml ) Need Help??

in reply to Documenting non-public OO components

You can place your internal methods in a Foo::Devel package which acts as a helper module and has its own pod. That will seperate both them and their documentation from the public, while leaving them accessible to all.

From the sound of it, your modules seem pretty tightly bound to each other. Could a redesign produce a more natural split of responsibilities?.

After Compline,

  • Comment on Re: Documenting non-public OO components

Replies are listed 'Best First'.
Re^2: Documenting non-public OO components
by creamygoodness (Curate) on Sep 06, 2005 at 16:21 UTC

    Well, the big project I'm working on is an overhaul of Plucene, the perl port of the Java Lucene search engine library I'm moving a couple things around, but for the most part it should stay as is, and Lucene's pretty well designed.

    Beyond that, I'm not sure that it makes sense to constrain development via a severe public-class-all-things-public / devel-class-all-things-devel split. You could do that, but there are bound to be occasions when you wish you could add a protected method to that public class. For sure, it's a good idea to divide responsibility, but unless you take draconian measures, the problem still exists.

    Marvin Humphrey
    Rectangular Research ―

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://489575]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (5)
As of 2022-12-05 11:08 GMT
Find Nodes?
    Voting Booth?

    No recent polls found