static and protection

[Kevin Bealer]

In article <du5hau$2b94$1 at digitaldaemon.com>, Hasan Aljudy says...
>
..
>That's OOP, which bythe way, is a purist paradigm. I know D is not for 
>language purists, but OOP must be supported properly.
>
>Can you give me a real life example where one class needs to expose 
>certain parts of itself to only one or two other classes? and why would 
>providing a public accessor for this feild be a bad thing?

Yes.  We have classes at work that interact.  We decided to make them friends.
We have clients that use these classes.  If the classes weren't friends, and we
provided the accessors, then *at that moment*, what you say is true, nothing
would break.  We can provide all the guarantees of validity, etc.

But if we change the implementation of this class by removing or renaming a
field or method, which we often do, then all the clients of the code outside our
team, (we are writing library code, among other things) will need to change
their usage of it if they happen to use that method or field.

We're not "hiding" data from clients.  If clients ask for access to the
information, we virtually always give it to them.  But we need to know what
people are using and what they aren't.  Otherwise, we remove a method, and break
code in a dozen other projects.

If they are using something, we try to avoid changing it, or communicate first
at least, and phase-in changes slowly.   The second kind (the private API that
only friends see) we are free to change without warning as long as *our* code
works with the change.

So I guess it's a people thing, not a code thing.

Kevin