Focus

[Andrey]

> In theory and according to the OOP concept they might not be 
> needed but when it comes to actually implement a OO concept it 
> can turn out to be handy to have. That is, accessing a private 
> member in the same module.

Allright. But I don't see a reason why this coudln't be done with 
nested classes. If some class wants frequently to access parent's 
members, then it preferably demands constant reference to it and 
therefore need to be presented as inner class. Then we can better 
and more intelligently track the existence and cooperation of 
both classes.

And, as it was said, there is no actual encapsulation unless you 
have organized runtime access checks to the memory chunk occupied 
by an object. Maybe the creators of D can implement this using 
contract programming or other things, I do not know. But this can 
be really a huge step towards safety. The real effect may be seen 
if the whole OS is written in object oriented manner, and its 
processes and services have the built-in hierarchical access 
policy. Such architecture makes possible natural cooperation 
between various core modules, processes and the user space. Maybe 
even existence in one address space without the need of slow 
artificial system calls.

If someone wants to continue discussing OOP, then I suggest to 
move to another thread to stop polluting this topic. Although I 
think that there are enough debates around OOP in the Internet 
already and yet another one will not make difference.