www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Module-level visibility

reply bearophile <bearophileHUGS lycos.com> writes:
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
Feb 15 2010
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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. Ali
Feb 15 2010
next sibling parent reply retard <re tard.com.invalid> writes:
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.
Feb 16 2010
parent Nekuromento <Necroment gmail.com> writes:
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.
Feb 16 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 16 Feb 2010 10:23:17 -0500, retard <re tard.com.invalid> 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.

Sure they do. It's called package. What D doesn't have is essentially Java's private protection -- protect this data, even from classes in the same package (module). In the end, I think it's a wash, since the person writing a module is writing all the classes and knows what each class does. Is it nice to be able to say, even within this module, disallow access? Perhaps. But perhaps it's not so important. Experience is on the side of Java, but it's difficult to say that D's approach is wrong. It threw me off the first time I saw it too, but I just don't think about it now. It generally doesn't get in the way. I don't really have any problems with friend in C++, I just look at D's method as another way to do it without using a keyword. -Steve
Feb 16 2010
prev sibling parent retard <re tard.com.invalid> writes:
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.
Feb 16 2010
prev sibling next sibling parent grauzone <none example.net> writes:
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.

Or just add C++'s friend class declarations? I heard C++ programmers rather dislike them, why is that?
 Bye,
 bearophile

Feb 15 2010
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hlcl4c$2ack$1 digitalmars.com...
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.

Interesting thing for them to say, considering that they don't actually know the language.
 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.

I'd certainly feel more comfortable with private being current-class-only and having a new "module" access that works like private currently does. But I can live with it as it is.
Feb 15 2010
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
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 think that's because in C#/Java data-hiding is conceived as an object oriented feature. It is not really surprising, since data hiding is the principal means of modularity and in C++/C#/Java that can (almost) only be achieved on the class level. It kinda makes sense for D to support data-hiding on the module level since object orientation is not the only or privileged programming style.
Feb 15 2010
prev sibling next sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
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.

I think D's approach makes very much sense. In D, the one writing the class will most likely also write the rest of the module, so one can assume they know what they're doing. Also, the module is imported as a whole, and what happens within it is not visible to the user. In Java, you don't have modules, nor do you have top-level functions, so classes play somewhat the role of D's modules. As a library user you import the class, and it would be disastrous if you could suddenly play around with its private members. -Lars
Feb 16 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello bearophile,

 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.

IMHO: D needs this feature or something like friend in C++. I prefer the current solution as it is simpler and I've never run into problems with it (and I have with friend). -- ... <IXOYE><
Feb 16 2010
prev sibling parent reply "Bob Jones" <me not.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hlcl4c$2ack$1 digitalmars.com...
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.

There's probably a whole bunch of features you could do the same with. 2 public classes in one file for example. FWIW Delphi has the same 'module' (unit in Delphi speak) level visibility. And in 10 years of using it I've never had a problem with it. There needs to be some way to make some features visible between interdependant classes or else you end up having to make things public that only needed to be public to a few classes. It would reduce encapsulation in a bad way because you end up having to expose things to users of the module or library that they dont need to see. Because it's either visible to everyone or visible to no-one. So anyone who recoils at such a feature does so for ideological reasons not from experience in my opninion. But really whats needed is 'class private' and 'module private'. Then the idealists and the pragmatists will both be happy. :-)
Feb 16 2010
parent retard <re tard.com.invalid> writes:
Tue, 16 Feb 2010 12:49:34 -0600, Bob Jones wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:hlcl4c$2ack$1 digitalmars.com...
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.

There's probably a whole bunch of features you could do the same with. 2 public classes in one file for example. FWIW Delphi has the same 'module' (unit in Delphi speak) level visibility. And in 10 years of using it I've never had a problem with it. There needs to be some way to make some features visible between interdependant classes or else you end up having to make things public that only needed to be public to a few classes. It would reduce encapsulation in a bad way because you end up having to expose things to users of the module or library that they dont need to see. Because it's either visible to everyone or visible to no-one. So anyone who recoils at such a feature does so for ideological reasons not from experience in my opninion. But really whats needed is 'class private' and 'module private'. Then the idealists and the pragmatists will both be happy. :-)

Well, one feature that comes to mind are nested/inner classes. I've often wrapped the classes inside an outer class to provide access to some shared data.
Feb 16 2010