in reply to Private Classes - Same or Separate Files?

I'd probably go with My::A::B or even My::A::_B [ because a leading "_" is standard Perl "style" for "private, please do not touch" ].

If the code is very small, I'd put it all in one file. If not, I'd put it in a separate file. [ Though size is not the only issue. If My::A::B's code is easier to maintain by keeping it in the same file or vice versa, then that is a good thing to base your decision on. I like keeping it in the same file as an indication that the code is private to My::A, but would expect that consideration is often outweighed. ]

I'd also put it in a separate file if there is a possibility of using My::A without ever using My::A::B. In that case I'd be sure to require My::A::B only when I decide I need it and never use it.

Personally, I'd hate to see code in My::A::B's constructor that tries to enforce that only code from My::A may call it. [ I tried to come up with a short justification for my feelings here, but failed. There are a lot of aspects to it. Such protection usually can be gotten around so you are just making it a little harder. So why waste the cycles? Why add that extra code that can be a source of bugs? I've had to work around bugs in modules and finding code like this that makes such work-arounds harder just makes you want to shoot the module author for spending that time writing that code rather than spending time on real improvements so maybe you wouldn't have to be working around the problem... ]

[ Updated. ]

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: (tye)Re: Private Classes - Same or Separate Files?
by mr_mischief (Monsignor) on Mar 06, 2002 at 17:17 UTC
    Indeed it seems that if you write code that ensures it is only run by the right parent, it defeats one of the main purposes of encapsulating it as a package. Code reuse is a good thing, not an evil to be guarded against.