🚀 go-pugleaf

mfinney@inmind.com writes:

>In <AFwV3Hn027@qsar.chem.msu.su>, "Eugene Radchenko"
><eugene@qsar.chem.msu.su> writes:
>>But it is not. Inheritable friendship is a natural extension of normal
>>friendship (for tightly coupled classes) to tightly coupled hierarchies.

>Exactly.  And, not only have I considered, I have begged for it
>on bended knee.  ...

>And it is NOT the same thing as making
>the attributes public.  It is the same thing as making them
>protected in another hierarchy.

Please notice that I did not say inherited friendship is the same
as making the members public. I said the effect on program design
and maintenance is the same.

If friendship is inherited, you cannot know what functions will
depend on the details of the private parts of the class. You cannot
know whether the unknown writers of these unknown functions will
get right all the inter-relationships among the private parts.
Since you don't know what programs will break if you make any changes
to the private parts, and you have no assurance of the correctness of
the use of these private members by unknown functions, you lose nothing
by making them public. By making them public, you avoid the false
sense of security which the "private" label seems to confer.

The point of making members private is that you have complete 
knowledge of who has access to them. If you need or want to make a
change, you know exactly who will be affected. If you allow friendship
to be inherited, you lose that knowledge, and private status 
provides no advantage.

Perhaps you can provide an example where inheritable friendship
gives a distinct advantage over making the members public. Bear
in mind that people you don't know about will be depending in
ways you don't know about on the private details of the class.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]