Module-level visibility

[retard]

Tue, 16 Feb 2010 13:31:25 -0500, Nekuromento wrote:

> retard Wrote:
> 
>> Mon, 15 Feb 2010 15:48:49 -0800, Ali Çehreli wrote:
>> 
>> > bearophile wrote:
>> >> I have shown this little program to some of my friends that program
>> >> in Java/C#:
>> >> 
>> >> class Foo {
>> >>     private int x;
>> >> }
>> >> void main() {
>> >>     Foo f = new Foo;
>> >>     f.x = 5;
>> >> }
>> >> 
>> >> 
>> >> When I say them this code compiles with D2 they usually tell me that
>> >> the compiler has a bug. So I suggest Walter to ask other people,
>> >> maybe at Google or else (and in this newsgroup too), if they think
>> >> this feature of D2 is a good thing, before this feature is set in
>> >> stone in D2 (I have no definite answer about this topic, I can't
>> >> help you). If you are really sure this is a good feature, then you
>> >> can ignore this post.
>> >> 
>> >> Bye,
>> >> bearophile
>> > 
>> > I don't have much experience with D, but I think this feature is
>> > useful. It solves the problem of giving access rights to a select
>> > few, in addition to the class itself.
>> > 
>> > In C++, it is sometimes sought to allow some classes to have more
>> > rights than the general public. For example, let the public have read
>> > access to certain features, but let some classes have write access.
>> > 
>> > In D, that select few is the module by default, and may be extended
>> > to the package.
>> 
>> In languages like Java/C#/Scala, there is no friend attribute. Still
>> major applications can be built. According to some OOP principles
>> accessing the internal state is often a design error. There might be
>> some efficiency issues, but other than that, I guess the large number
>> of Java/ C# programs clearly shows that 'friendship' is not a critical
>> feature. IMHO the implicit friendship feature inside the same module
>> causes more problems than advantages also in D.
> 
> In Delphi protection attributes behave the same as D ones. Module is
> commonly developed by one person, so he know what he can mess around
> with and what should be protected from others. So default 'friendliness'
> of classes within module is an advantage from my point of view, though
> it can lead to close coupling of classes in some cases. Also C# has
> 'internal' attribute which opens access to everyone within current
> assembly to class members marked with it.

I can believe that it helps sometimes because that's the only good 
argument behind friend relationship.

Now, what worries me is that if you inherit from a class which uses the 
friend feature, you might need to refactor the code to allow overriding 
some features in the derived classes. Some concrete examples would help 
here. I can think of some bad ones, but I've never used the friend 
feature anywhere.