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.

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 ...

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.

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

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.

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.

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.

"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)".

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.
> 
<snip>
> 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.

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.