Module-level visibility

[retard]

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.