Community

On 1/18/2013 4:55 PM, Andrey wrote:
> Are nested classes quite more perfectly suited for this? In my containers I
> implement iterator interface using nested class. Then I can easily construct
> mycontainer.new Iterator and have (should have by theory) access to protected
> (not private) members. Also I will be ensured that this is a proper iterator and
> that it can be constructed only when I have the instantiated parent container.
>
> And after that D forces you to restrict access not via default language
> construct, but via having one declaration per file. I think this is a not
> correct. In OOP concept you don't have such thing as a file or module. There are
> no files, there is ONE program with multiple data structures and hierarchies,
> united under one super root. Well, at least, that is how this supposed to work
> from the start.
This all falls apart once you decide you need "friend" access.

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

On 01/19/2013 01:04 AM, Andrey wrote:
>>> MyStruct ms;
>>> ms.a = 42; //!!!
>>> writeln(ms.a);
>>
>>
>> This is by design, not a bug. All code in a module has access to all
>> private members in that same module. This obviates the need for the
>> C++ "friend" declarations.
>
> Wikipedia states:
>
> «In general, encapsulation is one of the 4 fundamentals of OOP
> (object-oriented programming). Encapsulation is to hide the variables or
> something inside a class, preventing unauthorized parties to use.»
>
Even if this definition was accurate, note that it does not state what
"unauthorized" means. Languages that implement OOP can (and do) vary in
this aspect.
Also, it goes on like:
«So the public methods like getter and setter access it and the other
classes call these methods for accessing.»
Obviously the author of that sentence had no idea what encapsulation is
about!
> So how am I supposed to hide the variable inside the struct or class? I
> don't want anything to access it outside struct definition. And I don't
> see any point in giving the opportunity to access it using "friend"
> invitation. I'm sure "friend" explodes the basics of OOP encapsulation
> mechanics.
>
No it does not. "friend" attempts to work around the inexpressiveness of
accessibility modifiers.
> Struct is an «container» that owns its declarations and use special word
> for this: private. Then comes completely another data structure and can
> easily manipulate private members of another. Only imagine the other man
> from the neighbor house comes into your house and take your children
> without asking only because he lives on the same street.
The module is the house, not the street. "Encapsulation" is sometimes
applied (or pseudo-applied) at a way too small scale by programmers who
do not understand it. It is not magic.

On 1/18/2013 6:50 PM, Andrey wrote:
> And for that reason we have a simple helper "friend" in C++.
C++ friends are quite complex and are a giant pain. D's method of everything in
a module being implicitly a friend has been working very well for 10 years now.

On Saturday, 19 January 2013 at 03:40:35 UTC, Walter Bright wrote:
> On 1/18/2013 6:50 PM, Andrey wrote:
>> And for that reason we have a simple helper "friend" in C++.
>
> C++ friends are quite complex and are a giant pain. D's method
> of everything in a module being implicitly a friend has been
> working very well for 10 years now.
That is also the way to go IMO.
The usual definition of encapsulation is way too much object
centric. In many language, you'll find out that a class == a
module (or pretty much in practice). This don't fit at all
multi-paradigm, where D does pretty well.

>
> That is also the way to go IMO.
>
> snip
This isn't directed at you, or any other poster for that matter
(I am to technically inept to figure out how to post to the
thread other than using the 'reply' feature)...
Anyway, just wanted to say that this thread got off topic in an
awful hurry.

>
> snip
>
> Anyway, just wanted to say that this thread got off topic in an
> awful hurry.
It sort of funny that the thread started off with a complaint
about Walters lack of focus and quickly got off topic. Maybe
lack of focus is a common attribute of people interested in D.
I suggested that D be renamed the ADD language.

On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe wrote:
> On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:
>> So how am I supposed to hide the variable inside the struct or
>> class?
>
>
>> I'm sure "friend" explodes the basics of OOP encapsulation
>> mechanics.
>
> http://www.parashift.com/c++-faq/friends-and-encap.html
>
> If you have helper structures it can be useful to get at the
> private parts anyway, for example an iteration range.
http://yosefk.com/c++fqa/friend.html#fqa-14.2
Unfortunately this applies to D in some kind of speaking.

Am 19.01.2013 03:50, schrieb Andrey:
>> 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).
>
In .NET languages this is internal access.
In JVM languages, package default access.
So there is a need for such features.
--
Paulo