January 19, 2013
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.

January 19, 2013
> 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.
January 19, 2013
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.
January 19, 2013
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.

January 19, 2013
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.
January 19, 2013
>
> 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.
January 19, 2013
>
> 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.
January 19, 2013
Here is a helpful discussion on stack overflow about whether friend in
C++ breaks encapsulation:
http://stackoverflow.com/questions/1093618/how-does-the-friend-keyword-class-function-break-encapsulation-in-c

Also an article on encapsulation by Scott Meyers: http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197

Basically I think the consensus is that encapsulation != everything is private. Also I like Meyer's point that encapsulation is a means, not an end.



On 18 January 2013 20:11, Craig Dillabaugh <cdillaba@cg.scs.carleton.ca> wrote:
>>
>> 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.



-- 
   -=Miles Stoudenmire=-
   miles.stoudenmire@gmail.com
   estouden@uci.edu
   http://itensor.org/miles/
January 19, 2013
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.
January 19, 2013
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