[interfacekit] Re: An idea

These BXXXInternals classes would exist only to formalize and properly
abstract access to a given class's private internals, so no change would
happen in the public/protected interfaces (in fact, no real change to
private vars & methods would be necessary either).  The main point is
that while (for example) BView needs access to aspects of BWindow that
shouldn't be generally available, granting total access to BWindow's
internals is not a clean way to go about it.  Think of it as a proxy to
BWindow's privates. ;)  Something thin, maybe entirely inline if we can
manage it to avoid introducing any additional runtime overhead.

As for what classes other than BView and BWindow this applies to, I'm on
a windows box right now so I can't say -- but a casual browse through
the core Interface and App Kit class headers should be sufficient to
reveal the extent of the practice.

e

DarkWyrm wrote:
> 
> >
> >I've noticed in reviewing the App and Interface Kits that a large number
> >of classes are friends with other classes.  While I realize that this is
> >mostly happening between core kit classes that need to interact at a
> >more intimate level than C++ access specifiers alone can manage, I find
> >it personally disturbing when a class has a list of 6 friend classes. ;)
> >So here's what I'd like to propose:
> >
> <snip>
> >
> >Anyway, unless anybody has a major objection, this is how I'd like to
> >see things get implemented.  Comments?
> >
> >e
> Sounds ok to me so far as long as it doesn't change public member class
> access. Aside from BWindowInternals, any other specifics?
> 
> --DW

Other related posts: