www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - implicit "friend" is wrong (opinion)

reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
I was kind of surprised to see that all classes in the same file have 
access to each others private parts (pun intended).

The rationale was: "In D, friend access is implicit in being a member of 
the same module. It makes sense that tightly related classes should be 
in the same module, so implicitly granting friend access to other module 
members solves the problem neatly".

Well, it does "makes sense that tightly related classes should be in the 
same module", but it does not make sense the other way aorund.
It does not make sense that classes in the same file should be tightly 
coupled .. this is a matter of style. I personally don't like creating a 
file for everyting single class even if it's only 5 lines long, so I put 
them all in one file; this doesn't mean that I want them to be friends 
and have access to each other's private fields.

I wouldn't mind if these friends only had access to "protected" fields 
.. but private? that's upsetting.

This "friend" thing is considered bad anyway, why should it be implicit? 
I think it should always be explicit. It's not something that people 
want to do all the time, quite the opposite, it's something that people 
shouldn't be doing.

I don't see how making "friend" implicit solves any problem .. on the 
contrary, I think it creates one: now it's more like java, every class 
should have its own file. kind of limits my freedom, I don't like that.
May 10 2005
next sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
Hasan Aljudy wrote:
 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.

How does it limit your freedom? Just because elements in the same file have private-access (actually its better to say they have total access, the protection attributes just don't matter within the module, only outside) doesn't mean you /have/ to write code that toys with them? Its your module, meaning its your code, meaning you are free to do whatever the heck you want. Isn't that the definition of freedom? I fail to see how this creates any problems at all. But perhaps its just different milage. -- Chris Sauls
May 10 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Chris Sauls" <ibisbasenji gmail.com> wrote in message 
news:d5r183$1n5p$1 digitaldaemon.com...
 Hasan Aljudy wrote:
 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.

How does it limit your freedom? Just because elements in the same file have private-access (actually its better to say they have total access, the protection attributes just don't matter within the module, only outside) doesn't mean you /have/ to write code that toys with them? Its your module, meaning its your code, meaning you are free to do whatever the heck you want. Isn't that the definition of freedom? I fail to see how this creates any problems at all. But perhaps its just different milage.

Agreed on 100% percent. Andrew.
May 10 2005
prev sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Chris Sauls wrote:
 Hasan Aljudy wrote:
 
 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.

How does it limit your freedom? Just because elements in the same file have private-access (actually its better to say they have total access, the protection attributes just don't matter within the module, only outside) doesn't mean you /have/ to write code that toys with them? Its your module, meaning its your code, meaning you are free to do whatever the heck you want. Isn't that the definition of freedom? I fail to see how this creates any problems at all. But perhaps its just different milage. -- Chris Sauls

Well, first of all, that's not exactly the point. Secondly, it limits my freedom because I want to write OO code, if "private" becomes useless inside a file, then the only way to write good OO is to make new files for new classes. I want to write multiple classes inside one file, without having to worry about coupling (aka voilation of encapsulation).
 Just because elements in the same file
 have private-access doesn't mean you /have/ to write code that toys
 with them?

to my data, as it triggers a compiler error. There are practical reasons for that. When this attribute becomes useless, then the code will compile with no errors. Which means I could have what would be considered an error, but the compiler will not notify me about it. This is why I would /have/ to write classes in different files .. becuase I don't want to just hack some code together to make something "work". Again, that's not exactly the point, even if it didn't limit my freedome, it'd still be bad, becuase friend is not something very usefull that always comes up in projects, it's really just a "hack" that shouldn't really be used, and when it does get used, it must be used with extreem care. I just don't see any reason to make it implicit.
May 10 2005
next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
news:d5r54s$1ra2$1 digitaldaemon.com...
 Chris Sauls wrote:
 Hasan Aljudy wrote:

 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.

How does it limit your freedom? Just because elements in the same file have private-access (actually its better to say they have total access, the protection attributes just don't matter within the module, only outside) doesn't mean you /have/ to write code that toys with them? Its your module, meaning its your code, meaning you are free to do whatever the heck you want. Isn't that the definition of freedom? I fail to see how this creates any problems at all. But perhaps its just different milage. -- Chris Sauls

Well, first of all, that's not exactly the point. Secondly, it limits my freedom because I want to write OO code, if "private" becomes useless inside a file, then the only way to write good OO is to make new files for new classes. I want to write multiple classes inside one file, without having to worry about coupling (aka voilation of encapsulation).

D is designed to be practical and simple. So the question is "what is a practical and simple way to break encapsulation"? C++ does it with "friend". Java doesn't allow it at all. D does it with modules. Obviously breaking encapsulation shouldn't be allowed for arbitrary customer code that uses a class. Code in the same module is not customer code and is not even code that is likely to abuse the other code in the module. Hence the module becomes a practical solution to the problem of how/when to break encapsulation. I don't think it violates OO.
 Just because elements in the same file
 have private-access doesn't mean you /have/ to write code that toys
 with them?

to my data, as it triggers a compiler error. There are practical reasons for that. When this attribute becomes useless, then the code will compile with no errors. Which means I could have what would be considered an error, but the compiler will not notify me about it. This is why I would /have/ to write classes in different files .. becuase I don't want to just hack some code together to make something "work".

how large are your modules? They are probably pretty big if private variables get lost/abused in them.
 Again, that's not exactly the point, even if it didn't limit my freedome, 
 it'd still be bad, becuase friend is not something very usefull that 
 always comes up in projects, it's really just a "hack" that shouldn't 
 really be used, and when it does get used, it must be used with extreem 
 care.
 I just don't see any reason to make it implicit.

That's a perfectly fine opinion to have, but have you in practice ever caught an error where you were abusing a private property in the same module? The only time I can think of where I would have noticed is when a subclass of std.stream.Stream was using a private variable that should have been protected instead. I changed it to protected just in case someone outside the module needed it.
May 10 2005
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
 Just because elements in the same file
 have private-access doesn't mean you /have/ to write code that toys
 with them?

to my data, as it triggers a compiler error. There are practical reasons for that. When this attribute becomes useless, then the code will compile with no errors. Which means I could have what would be considered an error, but the compiler will not notify me about it. This is why I would /have/ to write classes in different files .. becuase I don't want to just hack some code together to make something "work".

Private is ment to hide implementation details. Some language hide per class, others per hierarchie, D per module.
Again, that's not exactly the point, even if it didn't limit my 
freedome, it'd still be bad, becuase friend is not something very 
usefull that always comes up in projects, it's really just a "hack" that 
shouldn't really be used, and when it does get used, it must be used 
with extreem care.
I just don't see any reason to make it implicit.

It is exmplicit. You explicitly put two classes into one file. This doesn't happen implicitly! Anyway friend in C++ is meant to improve encapsulation not to violate it as you claim it would. Think about the alternatives. Eigther you can allow one class (only one) to access some private attributes, if this class realy needs to. The alternative is to use a public methods to access this variable, so all (not only one) class can access this attribute.
May 11 2005
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 10 May 2005 12:24:03 -0600, Hasan Aljudy wrote:

 I was kind of surprised to see that all classes in the same file have 
 access to each others private parts (pun intended).
 
 The rationale was: "In D, friend access is implicit in being a member of 
 the same module. It makes sense that tightly related classes should be 
 in the same module, so implicitly granting friend access to other module 
 members solves the problem neatly".
 
 Well, it does "makes sense that tightly related classes should be in the 
 same module", but it does not make sense the other way aorund.
 It does not make sense that classes in the same file should be tightly 
 coupled .. this is a matter of style. I personally don't like creating a 
 file for everyting single class even if it's only 5 lines long, so I put 
 them all in one file; this doesn't mean that I want them to be friends 
 and have access to each other's private fields.
 
 I wouldn't mind if these friends only had access to "protected" fields 
 .. but private? that's upsetting.
 
 This "friend" thing is considered bad anyway, why should it be implicit? 
 I think it should always be explicit. It's not something that people 
 want to do all the time, quite the opposite, it's something that people 
 shouldn't be doing.
 
 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.

I can't see anything wrong with your reasoning here. I have to agree with you. There is no necessary reason that the physical location of a class (i.e. in a specific file) should cause it to automatically have access to private members of another class, regardless of where that other class is located. However, as an arbitrary device, implemented to avoid an extra keyword for a commonly (misused?) coding style, it is a neat solution. But a side effect of this design decision is that it forces a particular coding style on all D coders - namely that if you want/need to have truly private members in a class, you are forced to have them in different files. The solution, which is to allow both coding styles to exist, seems simple enough. I would suggest that a keyword be used as an attribute of the 'module' statement to indicate to the compiler that classes in this module cannot see private members of other classes in the same module. Maybe something like ... private module myclasses; -- Derek Parnell Melbourne, Australia BUILD v2.07 is now available. 07/May/2005 http://www.users.bigpond.com/ddparnell/build/download.html 11/05/2005 6:55:19 AM
May 10 2005
prev sibling next sibling parent Andy Friesen <andy ikagames.com> writes:
Hasan Aljudy wrote:
 I was kind of surprised to see that all classes in the same file have 
 access to each others private parts (pun intended).
 
 The rationale was: "In D, friend access is implicit in being a member of 
 the same module. It makes sense that tightly related classes should be 
 in the same module, so implicitly granting friend access to other module 
 members solves the problem neatly".
 
 Well, it does "makes sense that tightly related classes should be in the 
 same module", but it does not make sense the other way aorund.
 It does not make sense that classes in the same file should be tightly 
 coupled .. this is a matter of style. I personally don't like creating a 
 file for everyting single class even if it's only 5 lines long, so I put 
 them all in one file; this doesn't mean that I want them to be friends 
 and have access to each other's private fields.
 
 I wouldn't mind if these friends only had access to "protected" fields 
 .. but private? that's upsetting.
 
 This "friend" thing is considered bad anyway, why should it be implicit? 
 I think it should always be explicit. It's not something that people 
 want to do all the time, quite the opposite, it's something that people 
 shouldn't be doing.
 
 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.

I don't think it's such a big problem because, frankly, I don't care all that much about access specifiers within my own code. I use access modifiers to control how *other* code uses my API. This is important because my unit tests can't do anything to protect me if that other code starts mucking around implementation details. -- andy
May 10 2005
prev sibling next sibling parent reply "Tony" <talktotony email.com> writes:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message
news:d5qu7o$1kq9$1 digitaldaemon.com...
 I was kind of surprised to see that all classes in the same file have
 access to each others private parts (pun intended).

 The rationale was: "In D, friend access is implicit in being a member of
 the same module. It makes sense that tightly related classes should be
 in the same module, so implicitly granting friend access to other module
 members solves the problem neatly".

 Well, it does "makes sense that tightly related classes should be in the
 same module", but it does not make sense the other way aorund.
 It does not make sense that classes in the same file should be tightly
 coupled .. this is a matter of style. I personally don't like creating a
 file for everyting single class even if it's only 5 lines long, so I put
 them all in one file; this doesn't mean that I want them to be friends
 and have access to each other's private fields.

 I wouldn't mind if these friends only had access to "protected" fields
 .. but private? that's upsetting.

 This "friend" thing is considered bad anyway, why should it be implicit?
 I think it should always be explicit. It's not something that people
 want to do all the time, quite the opposite, it's something that people
 shouldn't be doing.

 I don't see how making "friend" implicit solves any problem .. on the
 contrary, I think it creates one: now it's more like java, every class
 should have its own file. kind of limits my freedom, I don't like that.

Darn. I seem to be swimming against the current of popular opinion here. I agree with Hasan for the simple reason that I feel anything which violates encapsulation should be explicit. I agree that in practice it is unlikely to be a problem. However, it is nice to be certain that there is no inadvertent coupling. Tony Melbourne, Australia
May 10 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 11 May 2005 10:07:33 +1000, Tony wrote:


 Darn.  I seem to be swimming against the current of popular opinion here.
 
 I agree with Hasan for the simple reason that I feel anything which violates
 encapsulation should be explicit.
 
 I agree that in practice it is unlikely to be a problem.  However, it is
 nice to be certain that there is no inadvertent coupling.
 
 Tony
 Melbourne, Australia

I'm with Hasan too ;-) But I'm willing to compromise if we can have both coding styles enabled. BTW, I'm based in Ormond. Where are you? -- Derek Melbourne, Australia 11/05/2005 10:12:28 AM
May 10 2005
parent "Tony" <talktotony email.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1ij7494v296ax$.11p7zru21utm3.dlg 40tude.net...
 On Wed, 11 May 2005 10:07:33 +1000, Tony wrote:


 Darn.  I seem to be swimming against the current of popular opinion


 I agree with Hasan for the simple reason that I feel anything which


 encapsulation should be explicit.

 I agree that in practice it is unlikely to be a problem.  However, it is
 nice to be certain that there is no inadvertent coupling.

 Tony
 Melbourne, Australia

I'm with Hasan too ;-) But I'm willing to compromise if we can have both coding styles enabled. BTW, I'm based in Ormond. Where are you? -- Derek Melbourne, Australia 11/05/2005 10:12:28 AM

Hi Derek, I had to look up "Ormond" in my Melway :) You aren't that far away from me. I'm in Vermont. Tony Melbourne, Australia
May 11 2005
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Tony wrote:
  > Darn.  I seem to be swimming against the current of popular opinion 
here.
 
 I agree with Hasan for the simple reason that I feel anything which violates
 encapsulation should be explicit.
 
 I agree that in practice it is unlikely to be a problem.  However, it is
 nice to be certain that there is no inadvertent coupling.
 
 Tony
 Melbourne, Australia

Hehe, Thanks. Yeah, I don't know what's wrong with the current here, maybe this issue is irrelevant for people who don't really do OOP, but lemme put it this way: D is *not* a procedural-only language, it's not "C", OO is important people!! there are reasons for making things private, the simplest of them is to reduce coupling. Information hiding, encapsulation, high cohesion and low coupling are all desirable, so why make it so easy to voilate them? This encourages bad coding practices. See, it's not just to prevent errors, but I think we should *not* encourage bad coding practices by making them so easy. They should atleast require some explicit declaration. C++ is already hated by many OO junkies becuase it's so easy to just break all the OO rules, why would D carry out the same faults of C++? If you look at some C++ projects, you'll see alot of bad coding styles (e.g. abuses of friends and protected) .. why is that? becuase C++ allows you to do that! When you make it so easy for people to write OO code then voilate OO rules, you can be sure that people are gonna use the features that voilate the rules of what's considered to be good coding style, and this will only give D a bad reputation, as a language that is not good for OOP. People who don't really write OO code probably won't realize the point of this, but people who do OO all the time do realize it, I don't think this "feature" of D will appeal to many of them. D is suposed to be *practical* and simple, but this does not mean it should provide simple ways of writing bad code .. becuase this totally contradicts the "practical" part. If it's easy to write bad code, then the language is probably not that practical. In my opinion, if you want an easy way to break encapsulation, just make everything public, or don't write OO code.
May 10 2005
next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Hasan Aljudy wrote:
 People who don't really write OO code probably won't realize the point 
 of this, but people who do OO all the time do realize it, I don't think 
 this "feature" of D will appeal to many of them.
 
 D is suposed to be *practical* and simple, but this does not mean it 
 should provide simple ways of writing bad code .. becuase this totally 
 contradicts the "practical" part. If it's easy to write bad code, then 
 the language is probably not that practical.
 In my opinion, if you want an easy way to break encapsulation, just make 
 everything public, or don't write OO code.

I come from a C++/mostly Java background, so have been coding 'OO' for a while. I'm not a purist, and it doesn't matter to me what happens within a library. I view the object oriented paradigm as a *guideline* to good design practices, and not as a set of 'rules' that must be adhered to. From this perspective, all that matters to me is that the language allows me to easily implement my object oriented design while allowing me to hide the implementation details from clients where needed. I can easily see the perspective you are coming from, but to me it's just as easy to see it another way. Encapsulation is meant to hide implementation details - clients can use a standard interface and I can change the implementation behind the scenes without them ever knowing. Considering that the module in which a class resides is part of the implementation, then module-level access to private class members does not break encapsulation. Yes, you can counter that it's easy, particularly on large teams, to screw things up by setting a class member directly rather than manipulating it via a setter method, but to me that's an issue that belongs in the realm of coding standards rather than language features. Personally, I like it that I don't need to explicitly declare friends. If we did allow a friend keyword, would you be allowed to declare them outside of the module? Outside of the package? That, in my mind, *does* break encapsulation where the current case doesn't. So I would prefer leaving things as is, but if we must have a special keyword for it then it should be restricted to module scope.
May 11 2005
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Mike Parker wrote:
 Hasan Aljudy wrote:
 
 People who don't really write OO code probably won't realize the point 
 of this, but people who do OO all the time do realize it, I don't 
 think this "feature" of D will appeal to many of them.

 D is suposed to be *practical* and simple, but this does not mean it 
 should provide simple ways of writing bad code .. becuase this totally 
 contradicts the "practical" part. If it's easy to write bad code, then 
 the language is probably not that practical.
 In my opinion, if you want an easy way to break encapsulation, just 
 make everything public, or don't write OO code.

I come from a C++/mostly Java background, so have been coding 'OO' for a while. I'm not a purist, and it doesn't matter to me what happens within a library. I view the object oriented paradigm as a *guideline* to good design practices, and not as a set of 'rules' that must be adhered to. From this perspective, all that matters to me is that the language allows me to easily implement my object oriented design while allowing me to hide the implementation details from clients where needed. I can easily see the perspective you are coming from, but to me it's just as easy to see it another way. Encapsulation is meant to hide implementation details - clients can use a standard interface and I can change the implementation behind the scenes without them ever knowing. Considering that the module in which a class resides is part of the implementation, then module-level access to private class members does not break encapsulation. Yes, you can counter that it's easy, particularly on large teams, to screw things up by setting a class member directly rather than manipulating it via a setter method, but to me that's an issue that belongs in the realm of coding standards rather than language features.

Actually, hiding implementation details from people who use my code is the least of my concerns .. I personally like to share knowledge, and I think information about the implementation details should be provided for those who want to know. Really, the purpose of making things private and public is to increase cohesion and reduce coupling, which in turn makes the code more maintainable. It's not important whether those who use the code know the implementation details or not, the important thing is to minimize coupling.. so instead of coupling directly to the data, you couple to the interface. Yes, it's a coding standard, but language features (imo) should encourage good coding standards. Which is why there is a "private" keyword in the first place .. there is nothing preventing you from making everything public, and nothing in the language features prevents the compiler from compiling a code that accesses private class members. I mean, it's not like a code that accesses private fields is code that cannot be compiled, it's just that the compiler will not compiler it for you. It's just a coding standad, enforced by the language features.
May 11 2005
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
Yeah, I don't know what's wrong with the current here, maybe this issue 
is irrelevant for people who don't really do OOP, but lemme put it this way:
D is *not* a procedural-only language, it's not "C", OO is important 
people!! there are reasons for making things private, the simplest of 
them is to reduce coupling.

Why is OO more important than other paradigms? This way of programming is way to limited. E.g. using delegates is simpler and way more convenient than using things like the observer pattern, command pattern, ... but it's 'not as OO'. So should we stop using them?
Information hiding, encapsulation, high cohesion and low coupling are 
all desirable, so why make it so easy to voilate them? This encourages 
bad coding practices.

Well there are many ways of acheaving this. e.g. component orientation. OR look at the SML module system. No OO at all, but you can easily achive information hiding, encapsulation, and low coupling.
See, it's not just to prevent errors, but I think we should *not* 
encourage bad coding practices by making them so easy. They should 
atleast require some explicit declaration.

So over oo-engeniring should be prevented by the language?
C++ is already hated by many OO junkies becuase it's so easy to just 
break all the OO rules, why would D carry out the same faults of C++?

Leave that junkies allown. Junkies aren't good for you.
If you look at some C++ projects, you'll see alot of bad coding styles 
(e.g. abuses of friends and protected) .. why is that? becuase C++ 
allows you to do that!

No, because C++ is a very complicated language that is hard to realy understand. Most peaople using it don't realy understand it. That's why they use it wrongly.
When you make it so easy for people to write OO code then voilate OO 
rules, you can be sure that people are gonna use the features that 
voilate the rules of what's considered to be good coding style, and this 
will only give D a bad reputation, as a language that is not good for OOP.

Bad coders stay bad coders. They can use something like VB.net instead. If the language prevents you from too many things it prevents beginners to write bad code, but it prevents good programmers from wrting good code as well.
People who don't really write OO code probably won't realize the point 
of this, but people who do OO all the time do realize it, I don't think 
this "feature" of D will appeal to many of them.

I do a lot of OO-programming.
D is suposed to be *practical* and simple, but this does not mean it 
should provide simple ways of writing bad code .. becuase this totally 
contradicts the "practical" part. If it's easy to write bad code, then 
the language is probably not that practical.
In my opinion, if you want an easy way to break encapsulation, just make 
everything public, or don't write OO code.

Well, if two classes are defined in two different modles it is impossible to break encapsulation. But impossible isn't easy, is it? I don't want to make everything public and I do want to write OO code. But this doesn't conflict in any way with D's access concept.
May 11 2005
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Matthias Becker wrote:
Yeah, I don't know what's wrong with the current here, maybe this issue 
is irrelevant for people who don't really do OOP, but lemme put it this way:
D is *not* a procedural-only language, it's not "C", OO is important 
people!! there are reasons for making things private, the simplest of 
them is to reduce coupling.

Why is OO more important than other paradigms? This way of programming is way to limited. E.g. using delegates is simpler and way more convenient than using things like the observer pattern, command pattern, ... but it's 'not as OO'. So should we stop using them?

I didn't say it's more important than something else, I'm just saying it is important. OO is not simple, it's complex, but once you setup the code correctly, the complexity of the code won't increase that much when the complexity of the problem increases. With other alternatives, the complexity of the code incrreases (explonentially, might I say) as the complexity of the problem increaes.
 
Information hiding, encapsulation, high cohesion and low coupling are 
all desirable, so why make it so easy to voilate them? This encourages 
bad coding practices.

Well there are many ways of acheaving this. e.g. component orientation. OR look at the SML module system. No OO at all, but you can easily achive information hiding, encapsulation, and low coupling.

Cohesion and Coupling were actually conceptualized for procedural programming .. Again, I didn't say that these concepts are only possible through OOP, but they are a big part of OOP. You don't have to write OO code if you don't want to, but this doesn't mean that the language can provide poor support for OO. (I'm not saying that D's suport for OO is poor, I'm just talking hypothatically)
 
See, it's not just to prevent errors, but I think we should *not* 
encourage bad coding practices by making them so easy. They should 
atleast require some explicit declaration.

So over oo-engeniring should be prevented by the language?

I didn't say anything about "preventing", all I'm saying is that things that would be considered bad coding poractices shouldn't be encouraged by making them implicit. I'm not saying don't allow them, just let them require some explicit statement.
C++ is already hated by many OO junkies becuase it's so easy to just 
break all the OO rules, why would D carry out the same faults of C++?

Leave that junkies allown. Junkies aren't good for you.

D is supposed to be a re-engineering of C and C++, so things that are considered bad shouldn't be carried out the same way.
If you look at some C++ projects, you'll see alot of bad coding styles 
(e.g. abuses of friends and protected) .. why is that? becuase C++ 
allows you to do that!

No, because C++ is a very complicated language that is hard to realy understand. Most peaople using it don't realy understand it. That's why they use it wrongly.

How is it that not understanding the language pushes the programmer to make many classes friends of each other?
 
When you make it so easy for people to write OO code then voilate OO 
rules, you can be sure that people are gonna use the features that 
voilate the rules of what's considered to be good coding style, and this 
will only give D a bad reputation, as a language that is not good for OOP.

Bad coders stay bad coders. They can use something like VB.net instead. If the language prevents you from too many things it prevents beginners to write bad code, but it prevents good programmers from wrting good code as well.

Don't prevent it, just make it require an explicit statement.
 
D is suposed to be *practical* and simple, but this does not mean it 
should provide simple ways of writing bad code .. becuase this totally 
contradicts the "practical" part. If it's easy to write bad code, then 
the language is probably not that practical.
In my opinion, if you want an easy way to break encapsulation, just make 
everything public, or don't write OO code.

Well, if two classes are defined in two different modles it is impossible to break encapsulation. But impossible isn't easy, is it?

I'm talking about implicit friendship among classes that are in the same module. what you talking about? dude ...
May 11 2005
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
I'm talking about implicit friendship among classes that are in the same 
module. what you talking about? dude ...

Some languages use keywords, this language uses modules for "friendship". Both is explicit. The language can't implicitly move two classes into one module. You allways have to manually place the classes into modules.
May 12 2005
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Matthias Becker wrote:
I'm talking about implicit friendship among classes that are in the same 
module. what you talking about? dude ...

Some languages use keywords, this language uses modules for "friendship". Both is explicit. The language can't implicitly move two classes into one module. You allways have to manually place the classes into modules.

ok ... um, there is no need to go philosophical, hehe, this is rediclious. Friendship /_*IS*_/ implicit. quote: http://www.digitalmars.com/d/cpptod.html#friends The D Way In D, friend access is implicit in being a member of the same module. /quote Of course the programmer has to do something to trigger this "implication", but it's still implicit. in C++, you can do something like: code: long x = ... short e = .... .. e = x; /code here, there is an implicit conversion form long to short. one can argue that it's not implicit because the coder explicitly said that he wants to assign a long value to a short variable, but that is just BS, the conversion here happens implicitly, becuase the coder didn't explicitly state that he wants to convert a long to a short. Java doesn't allow you to do that, you have to explicitly cast x to short. I hate philosophy. This kind of argument can never end, so please stop it.
May 12 2005
prev sibling parent reply "B.G." <gbatyan gmx.net> writes:
Question to strict OOPlers.

- Do you at least agree, it's ok to have semi-implicite friends, like 
protected class members in java (making protected members visible for 
the entire package)?

- Where I'm not 100% sure, is the question whether visibility of 
everything to everything (including private) inside a module is a good 
practice. Is there analogous behavior in other languages? Are there any 
negative experiences because of that? Any suggestions?
May 10 2005
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
B.G. wrote:
 Question to strict OOPlers.
 
 <snip>
 
 - Where I'm not 100% sure, is the question whether visibility of 
 everything to everything (including private) inside a module is a good 
 practice. Is there analogous behavior in other languages? Are there any 
 negative experiences because of that? Any suggestions?

Well, the way I see it right now, a module acts as a class, in terms of "private" and "public" attributes atleast. This is ok if a module is meant to be a way of encapsulating related data or some thing like that, but that's not very clear to me, I was assuming a module is just a file like a cpp file, and that the module concept was introduced to eliminate the need for .h files. The analogous behaviour in other languages (and in D itself) is the "class" .. ironic? The way things are built now, a module should only contains one class, having it contain more, is like mixing several classes into one class, since every method would have access to every member variable across all the classes. What I mean is, it seems to me that modules are meant to encapsulate a specific entity or functionality .. so really a source file is not just a grouping of source code (like cpp files), but it represents some sort of entity, which makes it more like java files. So, there is not much difference from java, in that each class needs to be in its own file. I would personally accept it if it was made clear that a module is an entity by itself that should be cohesive just like a class. i.e. you wouldn't make a class to draw images and recieve input at the same time (that would be a very uncohesive class), and so you shouldn't put unrelated functions or classes in one module. I'm kind of confused now myself, what exactly is a module? what's its purpose (why was it invented)? and, are .d source files meant to encapsulate an idea/entity/concept/functionbality like .java files? or are they just meant for organization, like .cpp files? Maybe there should be more focus on this area in the website, to clear the confusion. Because at first I was thinking of d files as "just source files", which is why I felt it's redicilous to have implicit friendship between classes in the same file, but now that I think about it in terms of "modules", it seems to me that modules are kind of a procedural alternative to the OO class concept. I'm still confused, as to why the idea was come up with? I still think there shouldn't be implicit friendship though, it must be explicit between classes even if they are in the same modules, becuase classes are one level down inside a module, if you know what I mean. You have several levels of privacy/locality. private modules variables are like global variables that are only visible inside the module. That's the highest level. The seocnd level is private class members, they should only be visible to the class, unless otherwise is explicitly stated. Kind of hard for me to explain. Think of it like this: assume we can have modules within modules, and we have moule 1, inside it module 2, inside it is module 3. things inside module 3 have access to all vriables in modules 1, 2, 3. things inside module 2 have access to all variable in modules 1, 2, and only public variables in module 3. things in module 1 only have access to public things in modules 2, 3 and everything in module 1. Kind of like a blackbox within a blackbox (blackbox1, inside it there is blackbox2). everything inside a blackbox knows the innder workings of it, blackbox2 is inside blackbox1, so bb2 knows how things in bb1 work, so it can access them. but for bb1, bb2 is a blackbox, bb1 doesn't know the inner works of bb2, so it shouldn't try to mess with it. See, in a class, all methods have access to the private variables, but, local variables inside a method are private to that method, other methods can't reference them, because they are private to the method itself, not to everything related to it. (local method variables don't really exist until the method is called, but I'm talking theoratically, so my point still stands) I hope you understand what I mean. It makes perfect sense to have private module variables and have them accessable only inside that module, but to me, it doesn't make sense to make things that are private to a class inside a module, to make them accessable to the whole module.
May 10 2005
parent reply "B.G." <gbatyan gmx.net> writes:
Hasan Aljudy wrote:
 B.G. wrote:
 
 Question to strict OOPlers.

 <snip>

 - Where I'm not 100% sure, is the question whether visibility of 
 everything to everything (including private) inside a module is a good 
 practice. Is there analogous behavior in other languages? Are there 
 any negative experiences because of that? Any suggestions?

Well, the way I see it right now, a module acts as a class, in terms of "private" and "public" attributes atleast. This is ok if a module is meant to be a way of encapsulating related data or some thing like that, but that's not very clear to me, I was assuming a module is just a file like a cpp file, and that the module concept was introduced to eliminate the need for .h files.

 The way things are built now, a module should only contains one class, 
 having it contain more, is like mixing several classes into one class, 
 since every method would have access to every member variable across all 
 the classes.

difference with java. Perhaps it's just the STYLE many developers have chosen to put every class into a separate module. Did I miss something??? I've read the language specs once more and here is my vision. If someone asked me to put the access control differences between java and D in a most simple way, I'd describe it as below. (This is my vision, I would appreciate any comments, if there's something wrong with it. I'm not a native english speaker, so wording might need to be changed too.) IMO, Compiling such a small tutorial would be VERY helpful for beginners. -= How to understand D access control if you know java access control =- 1) D allows multiple classes per compilation unit. Just for a minute imagine it WOULD NOT allow to do so. This way D source code layout would be exactly the same as in java. At this level, a 'package' in D terminology corresponds to a 'package' in java terminology. 2) rename 'protected' atribute in java code to read 'package'. ----- After these 'changes' java logic and syntax for access control has been 'translated' to D. Further is what makes D a more flexible language in terms of access control. 3) add 'protected' attribute with a new meaning of allowing _only derived_ classes to access the corresponding members. 4) Now allow multiple classes in a single compilation unit (file). In additions to the above access control, this gives a chance to relate some classes at the lowest possible level. That is, all members, regardless, 'private', 'package' or 'protected' even in different classes are visible for all other members inside a single compilation unit. These compilation units are called modules in D. In java a class simply belongs to a certain package. In D _in addition_ to that it also logically belongs to a certain module inside this package (even if that module consists of this single class only). Though, syntactically a class is declared to belong to a module and it implicitely belongs to the enclosing package.
May 11 2005
next sibling parent xs0 <xs0 xs0.com> writes:
http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html

package, private, protected and public are all the same as in Java, with 
the important difference that everything is visible to the module, 
regardless of the specifier.. there's also "export" that allows access 
to other executables, like in DLLs (if I got the doc right :)

I'm not sure what happens in D if you don't specify anything (in Java it 
gives access to package, but not subclasses.


xs0


 If someone asked me to put the access control differences between java 
 and D in a most simple way, I'd describe it as below. (This is my 
 vision, I would appreciate any comments, if there's something wrong with 
 it. I'm not a native english speaker, so wording might need to be 
 changed too.)
 
 IMO, Compiling such a small tutorial would be VERY helpful for beginners.
 
 -= How to understand D access control if you know java access control =-
 
 1) D allows multiple classes per compilation unit. Just for a minute 
 imagine it WOULD NOT allow to do so. This way D source code layout would 
 be exactly the same as in java. At this level, a 'package' in D 
 terminology corresponds to a 'package' in java terminology.
 
 2) rename 'protected' atribute in java code to read 'package'.
 
 ----- After these 'changes' java logic and syntax for access control
       has been 'translated' to D.
       Further is what makes D a more flexible language in
       terms of access control.
 
 3) add 'protected' attribute with a new meaning of allowing
 _only derived_ classes to access the corresponding members.

May 11 2005
prev sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
B.G. wrote:
 Hasan Aljudy wrote:
 
 B.G. wrote:

 Question to strict OOPlers.

 <snip>

 - Where I'm not 100% sure, is the question whether visibility of 
 everything to everything (including private) inside a module is a 
 good practice. Is there analogous behavior in other languages? Are 
 there any negative experiences because of that? Any suggestions?

Well, the way I see it right now, a module acts as a class, in terms of "private" and "public" attributes atleast. This is ok if a module is meant to be a way of encapsulating related data or some thing like that, but that's not very clear to me, I was assuming a module is just a file like a cpp file, and that the module concept was introduced to eliminate the need for .h files.

 The way things are built now, a module should only contains one class, 
 having it contain more, is like mixing several classes into one class, 
 since every method would have access to every member variable across 
 all the classes.

Errr, AFAIK a module can contain any nuber of classes, that's the difference with java. Perhaps it's just the STYLE many developers have chosen to put every class into a separate module. Did I miss something???

That's not what I mean .. you can techncally put as many classes in a single file as you want, but the current concept of a module suggests that a good coding practice is to put every class in its own file, except for those cases when you have to hack things. Like a class, good practices suggest that a class should be cohesive, so it does not make sense to make the class responsioble for two totally different tasks (like drawing images on the screen, and sending data over the network). So in the same sense, a module has to be cohesive, it does not make sense to put two totally seperate classes in one module (like a player class and a buffer class). Of course, you can go ahead and put everything in one huge class, just the same way as you can go ahead and put everything in one big module, but that would just be bad bad code.
May 11 2005
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Hasan Aljudy wrote:

 That's not what I mean .. you can techncally put as many classes in a 
 single file as you want, but the current concept of a module suggests 
 that a good coding practice is to put every class in its own file, 
 except for those cases when you have to hack things.

It doesn't suggest that to me.
 
 Like a class, good practices suggest that a class should be cohesive, so 
 it does not make sense to make the class responsioble for two totally 
 different tasks (like drawing images on the screen, and sending data 
 over the network).
 So in the same sense, a module has to be cohesive, it does not make 
 sense to put two totally seperate classes in one module (like a player 
 class and a buffer class).

How is that a problem? Several related classes in the same module, several related modules in the same package. If you don't want two classes being friendly (i.e. having access to each others private parts) as a design decision, then they likely don't belong in the same module. D is not C++. One does not implement a design in Java the same way one would in C++, simply because the language features are so different. It's the same with D. Just because you would implement a design one way in C++ does not mean that's the way you should implement it in D. Look at the features you have available and use them to implement your design accordingly. When using D, think in D.
May 11 2005
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Mike Parker wrote:
 Hasan Aljudy wrote:
 
 That's not what I mean .. you can techncally put as many classes in a 
 single file as you want, but the current concept of a module suggests 
 that a good coding practice is to put every class in its own file, 
 except for those cases when you have to hack things.

It doesn't suggest that to me.

 How is that a problem? Several related classes in the same module, 
 several related modules in the same package. If you don't want two 
 classes being friendly (i.e. having access to each others private parts) 
 as a design decision, then they likely don't belong in the same module.
 

Classes should generally never be friends, if you need some classes to be friends, there's probably a flaw in the design. it's not related classes that should be in the same module .. it's classes that are "tightly _coupled_", the keyword here is "coupling". Design should attempt to reduce coupling, not introduce it. Of course, it's the programmers decision to make, but good design should need to put each class in its own module.
May 11 2005
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Hasan Aljudy wrote:

 Classes should generally never be friends, if you need some classes to 
 be friends, there's probably a flaw in the design.
 it's not related classes that should be in the same module .. it's 
 classes that are "tightly _coupled_", the keyword here is "coupling".
 Design should attempt to reduce coupling, not introduce it.
 Of course, it's the programmers decision to make, but good design should 
 need to put each class in its own module.

Whatever term you use, it shouldn't make a difference within the same module. Tightly coupled designs are inflexible and a bear to rework, but unless you have a monolithic module (your whole app is in one module - yuck) then having classes within a module that are tightly coupled hurts nothing in the big picture. External modules still have access to whatever interface you choose to expose and don't know or care how loosely or tightly coupled classes are underneath. I understand what you are saying, but I think that the module concept adds a finer level of detail where you can violate your 'rules'. The module is not a client of itself, so it classes within it need not treat each other like strangers. If you wish to drill down and apply the OO paradigm at that level, fine. I just down see the usefulness of it, and would very much prefer things to stay the way they are.
May 11 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 12 May 2005 14:04:56 +0900, Mike Parker wrote:


[snip]
 I just down see the usefulness of it, and 
 would very much prefer things to stay the way they are.

I too think that the current semantics should remain. But in addition to that, is there any valid argument to allow the other paradigm to be utilized by a coder? In other words, what's so wrong with allowing a coder to create a strictly 'private' module in which the contained classes cannot see it's neighbors private areas? Is it a bad idea to enable D to allow coders the choice of paradigms? -- Derek Melbourne, Australia 12/05/2005 3:10:58 PM
May 11 2005
parent Mike Parker <aldacron71 yahoo.com> writes:
 I too think that the current semantics should remain. But in addition to
 that, is there any valid argument to allow the other paradigm to be
 utilized by a coder? In other words, what's so wrong with allowing a coder
 to create a strictly 'private' module in which the contained classes cannot
 see it's neighbors private areas?
 
 Is it a bad idea to enable D to allow coders the choice of paradigms? 
 

'private' and 'module' protection is fine. I just wouldn't want to see the current behavior removed altogether.
May 12 2005
prev sibling next sibling parent "B.G." <gbatyan gmx.net> writes:
What's really annoying for me is that the private/protected-part-sharing 
stuff must always reside in a single file.

I normally tend to write in a class-per-file fashion because it simply
makes code better 'readable'. This method is also frequently adhered to 
in existing projects. That is using class-per-file plus x.all 
metamodules, Which I personally find ideal for heavy OO applications.

The java approach wasn't that bad actually. OK, java _forced_ to use 
class-per-file, that's not ideal. D perfectly fixes that.

BUT, with java a package is splet into nice separate files and besides 
it's possible to 'extend' an existing package from some library and have 
access to the protected parts of the classes. Just put some classes into 
existing packages, and that's it.

Actually this option is not bad to have.

As for incapsulation disputes, IMHO, incapsulation-guarding techniques 
for a language should not be too restrictive. In most cases It's main 
purpose is to protect a programmer from his own _relatively obvious_ 
encapsulation misconceptions.

Putting a class _accidentally_ into an existing package has a very small 
probability.
May 10 2005
prev sibling next sibling parent reply Burton Radons <burton-radons smocky.com> writes:
Implicit friend was introduced before the "package" attribute was put 
in.  With that in there there's no longer any reason to have it work the 
way it does; "package" encapsulates all its functionality and doesn't 
interfere with most refactoring.

Eliding all the debate here, that's all it boils down to.  The utility 
for implicit friend - a weird left-field hack - is gone.  It should be 
removed.
May 11 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Burton Radons" <burton-radons smocky.com> wrote in message 
news:d5td14$19ai$1 digitaldaemon.com...
 Implicit friend was introduced before the "package" attribute was put in. 
 With that in there there's no longer any reason to have it work the way it 
 does; "package" encapsulates all its functionality and doesn't interfere 
 with most refactoring.

 Eliding all the debate here, that's all it boils down to.  The utility for 
 implicit friend - a weird left-field hack - is gone.  It should be 
 removed.

Back when the "package" keyword was being debated I argued for a flexible syntax like extern but applied to private. So a "private(package)" declaration would be visible in the package (today called package), "private(module)" would be visible in the module, "private(subclass)" would be visible in subclasses (today called protected). By default private would keep the "private(module)" meaning. I didn't suggest it at the time but something like "private(class)" or "private(scope)" or something could give class or scope protection. There's no problem with introducing new protection levels since the identifier is not a keyword. Of course that suggestion wasn't implemented and a new keyword was added for "package". That said it would be annoying to have nothing between "private(class)" and "private(package)", as you suggest. There must be some way to say "private(module)".
May 11 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
This is *not* rhetorical:

Is there any valid reason why anyone would need, or want, to place multiple
classes in the same file and ensure that those classes cannot see each
other's private information?

-- 
Derek Parnell
Melbourne, Australia
12/05/2005 6:33:05 AM
May 11 2005
next sibling parent reply Burton Radons <burton-radons smocky.com> writes:
Derek Parnell wrote:

 This is *not* rhetorical:
 
 Is there any valid reason why anyone would need, or want, to place multiple
 classes in the same file and ensure that those classes cannot see each
 other's private information?

- No other language with protection that I know of works in this manner, it's a great big and weird idiosyncracy. A mature language shouldn't be different just because it can be. - It interferes with object motility, trapping classes in a module. Protection does in general but particularly here. Anything that makes refactoring difficult has got a lot to answer to, and a feature which has been superceded by an explicit method that works better doesn't even begin to have enough utility to warrant that. - The language has some dodgy features that make enforced protection a good idea. For example: class Foo { private int value; } void bar () { float value; with (new Foo) value = 4; } Depending upon where bar is located it might have different effects, but it will never give any indication that it does.
May 11 2005
parent Burton Radons <burton-radons smocky.com> writes:
Burton Radons wrote:

 Depending upon where bar is located it might have different effects, but 
 it will never give any indication that it does.

Ah, that's not true - it complains that it can't access the field if it's moved outside of the module, so depending upon the private implementation of an object, your with statement could suddenly stop working. Eh, "with" sucks. It should be: with ([type] <identifier>; <expression>) <statement> It's just too dangerous a feature as it is.
May 11 2005
prev sibling next sibling parent Dejan Lekic <leka entropy.tmok.com> writes:
I totally agree on this - in same file naturally all classes should have
access to private parts of each other.

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
  
May 12 2005
prev sibling parent reply James McComb <ned jamesmccomb.id.au> writes:
Derek Parnell wrote:
 This is *not* rhetorical:
 
 Is there any valid reason why anyone would need, or want, to place multiple
 classes in the same file and ensure that those classes cannot see each
 other's private information?

Here are my reasons: [1]. By default, a class should not be able to see the data in another class (strict OOP says a class should encapsulate its data). [2]. A programmer should not have the inconvenience of being allowed only one class in each file just so that they can enforce rule [1]. For example, I put several related classes into one file for convenience, and then suffer strict-OOP guilt, because my classes are not encapsulated from each other. So I'm in favour of an explicit 'package' or 'module' access specifier. But I imagine Walter would be against it, because it makes it harder to throw together 'quick and dirty' apps. James McComb
May 12 2005
parent reply Burton Radons <burton-radons smocky.com> writes:
James McComb wrote:

 So I'm in favour of an explicit 'package' or 'module' access specifier. 
 But I imagine Walter would be against it, because it makes it harder to 
 throw together 'quick and dirty' apps.

Why would they use access protection if they're quick and dirty?
May 12 2005
parent James McComb <ned jamesmccomb.id.au> writes:
Burton Radons wrote:
 James McComb wrote:
 
 So I'm in favour of an explicit 'package' or 'module' access 
 specifier. But I imagine Walter would be against it, because it makes 
 it harder to throw together 'quick and dirty' apps.

Why would they use access protection if they're quick and dirty?

Quite right, I must have been confused. They'd just leave the access specifiers off altogether. James McComb
May 12 2005