View mode: basic / threaded / horizontal-split · Log in · Help
January 19, 2013
Re: Focus
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
Re: Focus
> 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
Re: Focus
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
Re: Focus
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
Re: Focus
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
Re: Focus
>
> 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
Re: Focus
>
> 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
Re: Focus
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
Re: Focus
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
Re: Focus
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
1 2 3 4 5 6
Top | Discussion index | About this forum | D home