This all falls apart once you decide you need "friend" access.
I haven't seen such situations yet. According to OOP concept they
must be very rare, so I tend to consider them more of
architecture and logic mistake (and C++ is one big architecture
and logic frankenstein).
Once again, in D you have active nested classes that can
automatically reference parent and this allows very nice and
accurate compositions. So the need for separate small supporting
class is eliminated, because it integrates into its parent.
Moreover, you preserve very well the "program with interface"
idiom.
For example, you have a List container and a Array container.
Then you have general iterator interface.
interface iIterator {...}
class List {
class Iterator : iIterator {specific implementation}
}
class Array {
class Iterator : iIterator {another specific implementation}
}
And then you can switch between two containers easily preserving
the rest of code: List.new Iterator <-> Array.new Iterator;
Of course, you can make this work by having two different factory
functions returning proper iterator implementation for class.
class List {
iIterator constructIterator() { return new
ListIterator(this); }
}
But this is artificial, speculative, not language feature.
Compiler still can't figure out any bond shared between classes.
And for that reason we have a simple helper "friend" in C++. D
understands the hierarchy, but for unknown reason refuses to take
full advantage of this feature. And we could use it to establish
concrete and specific links instead of outer module wrapper
container.
Well, I don't want to force any changes. Just trying to better
understand D. This became off-topic.
