On Friday, October 26, 2018 3:25:05 PM MDT 12345swordy via Digitalmars-d wrote:
> On Friday, 26 October 2018 at 20:55:00 UTC, Jonathan M Davis
>
> wrote:
> > On Friday, October 26, 2018 1:55:08 PM MDT 12345swordy via
> >
> > Digitalmars-d wrote:
> >> On Friday, 26 October 2018 at 19:45:48 UTC, David Gileadi
> >>
> >> wrote:
> >> > [...]
> >>
> >> If it deliberate, then it needs to be documented.
> >
> > What are you asking for exactly? The documentation documents exactly what the behavior is:
> >
> > https://dlang.org/spec/attribute.html#visibility_attributes
> >
> > "2. Symbols with private visibility can only be accessed from within the same module. Private member functions are implicitly final and cannot be overridden."
> >
> > Are you looking for the documentation to explain why there is a "loophole" to private that allows other symbols within a module to access private members of a class of struct?
>
> No I am asking why class B inherent the private variables of class A that is marked private, when we have the protected keyword.
>
> I don't know how else I can I make this any clearer.

If class B is in the same module as class A, it has access to all private members of class A. It comes from the fact that private is private to the module, not private to the class. private has _nothing_ to do with inheritance. As the documentation clearly states, "symbols with private visibility can be accessed from within the same module." The idea that any derived classes in the same module would then somehow not have access comes from assumptions based on how other languages work, not from how D works or how it's documented to work.

protected makes it so that derived classes - whether they be in the same module or elsewhere - can access that member. It also makes functions virtual. So, it _does_ have something to with inheritance. private, however, only has to do with modules. It has no affect on inheritance and does not make functions virtual.

Similarly, package makes it so that other symbols within the same package can access that symbol. It has no effect on inheritance and does not make functions virtual.

public is the only other attribute that affects inheritance or makes functions virtual, and it gives full access.

Don't assume that the various access levels work the way that they do in other languages that you've used, because odds are that they don't. Aside from the fact that export needs to be better explained, they work the way that the spec describes them:

https://dlang.org/spec/attribute.html#visibility_attributes

Your confusion stems from the fact that you're fixating on trying to restrict access at the class level, and that is _not_ how D is designed to work. The _module_ is the base level of encapsulation that D uses. package, protected, and public all provide ways to expand access - to the package, derived classes, and everything else respectively. But the idea that you're ever restricting access to the class or struct specifically is just plain false. If you want to do that, you need to put that class or struct in a module by itself. As soon as you put it in a module with _anything_ else - including derived classes - those other symbols are going to have access to the private members of that class or struct.

If you don't like that design decision, that's fine. As with almost all design decisions, there are pros and cons to it, but that doesn't mean that it has "holes" in it. It means that it defines private to mean something different from what C++, Java, C#, etc. define it to mean, and you're going to have an easier time here if you stop assuming that private means the same thing in D that it means in other languages or that it's even intended to mean the same thing.

You seem to keep making the mistake that visibility attributes have anything to do with restricting access at the class level in D, and they _never_ do. If you put other stuff in a module with a class, then that other stuff is going to have access to that class' members no matter what access level those members have. The visibility attributes affect which symbol outside of the module can then access those members, and in the case of member functions, it affects whether they're virtual, but it never affects whether anything else inside the module can access them.

- Jonathan M Davis

On Friday, October 26, 2018 3:30:25 PM MDT 12345swordy via Digitalmars-d wrote:
> On Friday, 26 October 2018 at 21:05:56 UTC, Steven Schveighoffer
>
> wrote:
> > On 10/26/18 3:28 PM, 12345swordy wrote:
> >> On Friday, 26 October 2018 at 18:57:00 UTC, Neia Neutuladh
> >>
> >> wrote:
> >>> On Fri, 26 Oct 2018 18:16:38 +0000, 12345swordy wrote:
> >>>> [...]
> >>>
> >>> D's `private` within a module is identical to Java's `private` within a class and its nested classes. The following is valid Java:
> >>>
> >>> [...]
> >>
> >> Again I am referring to classes in the module not the module itself.
> >
> > Classes in the module are in the module. So any classes in the module *are* the module itself.
> >
> > What it seems like you are saying is that you want non-derivatives to still be able to access private variables, but derivative classes are forbidden? Nothing personal, but this really doesn't make a lot of sense. I feel like maybe there is a misunderstanding.
>
> There is a misunderstanding! I am asking why the child class have the parent class private member variables in the first place!!! Do I need to write a DIP for you guys to understand what the hell I am talking about!?

Derived classes _always_ have the private members of their base classes, because the base classes are part of the derived classes. Derived classes extend the base classes and literally have the base class members inside of them and wouldn't work properly if they didn't. However, if they're in separate modules, then the derived class does not have access to them. They're there but inaccessible. That would be the same in C++, Java, C#, etc. The difference is that in D, if you then put them in the same module, the derived class then has access to the base class' member variables, because private is private to the module, not the class. You'd get the same in C++ if you made them friends, but you'd have to be explicit about it, since friends require you to be explicit about it.

- Jonathan M Davis

On Friday, 26 October 2018 at 22:42:42 UTC, 12345swordy wrote:
> You are right, I am better off continuing writing the dip about nested modules then argue ad nauseam about this.

Actually, if the programming language does correctly, what it defines as correct (as defined by it's specification), then it is correct (for that programming language).

"Correctness is the prime quality" - Bertrand Myers.

Now...in an 'object-oriented' language, classes are the only 'modules'.

That means, the class (the module) is the encapsulating unit by which you construct your program.

D is not an object-oriented langauges - although it does have classes.

Classes in D are NOT the modular units by which you are expected to construct your program; rather the module unit in D, is .. the 'module'.

All decisions about classes in D, seem to derive from that concept.

If you want the 'information hiding' capabilities that object-oriented languages offer to classes, then use an object-oriented language.

Many come to D from object-oriented languages, and expect classes to operate in the same way in D, as they did in those languages. It aint going to happen - in D. Why? Because the designers of D expect you to use the module, not the class, as the encapsulating unit for constructing your program.

Really, you are better off using a language that does what *you want* it to do, instead of getting the language to change it's concept of the modular unit.

If you persist in trying to change D's concept of what the modular unit is, then you will only get the type of responses that you are already starting to get, and, you persist - it will likely get worse (based on the history around similiar discussions of D's implementation of classes).

Move on, and use another language that doesn't redefine the traditional concept of a class, like D does - that is my advice ;-)

On Saturday, 27 October 2018 at 01:54:24 UTC, unprotected-entity wrote:

> D is not an object-oriented langauges - although it does have classes.

It like you never read the overview
https://dlang.org/overview.html
or the wiki
https://en.wikipedia.org/wiki/D_(programming_language)

> If you want the 'information hiding' capabilities that object-oriented languages offer to classes, then use an object-oriented language.

D IS an object-oriented language as much as c++, just not a pure one.

> Many come to D from object-oriented languages, and expect classes to operate in the same way in D, as they did in those languages. It aint going to happen - in D. Why?

"Have a short learning curve for programmers comfortable with programming in C, C++ or Java."
Gee, I wonder why?

> Really, you are better off using a language that does what *you want* it to do, instead of getting the language to change it's concept of the modular unit.
You didn't read the dip that I wrote did you? Nowhere in the dip did I change the concept of the modular unit. I just remove the one module per file Limination. That is it.

On Friday, 26 October 2018 at 22:01:42 UTC, 12345swordy wrote:
> On Friday, 26 October 2018 at 21:46:27 UTC, Laurent Tréguier wrote:

>> You simply seemed to be implying that private had the same effect as protected, which isn't the case.
> ... How can I make my self any more clear here!? When I say y behaves like x it I don't means y is exactly the x! Nor does it imply that!

Here's the example code from your issue #19334:

```
import std.stdio;
class A
{
    private int y;
}

class B : A
{
};

void main()
{
    B b = new B();
    b.y = 1; // Should be a compile error as class shouldn't have private int y.
    writeln(b.y);
}
```

First, this really is about encapsulation and *not* inheritance. Even if class B is in another module, it would still inherit y, i.e. it would have its own copy of y. private working as intended.

Second, A, B, and main are in the same module. The spec clearly says that everything in the same module has access to private members. I quoted it in the bug report and it's been quoted two or three times here. So main has access to y.

If used to be that even if you moved the declaration of B to another module, then main would still have access to y through b. That was deemed to be a bug an is now deprecated. But as long as they are all in the same module, it's working as intended.

On Saturday, 27 October 2018 at 03:20:43 UTC, Mike Parker wrote:


> still inherit y, i.e. it would have its own copy of y. private working as intended.


I meant to say "would have its own copy of y, but would be unable to access it".

On Saturday, 27 October 2018 at 02:49:00 UTC, 12345swordy wrote:
>
> D IS an object-oriented language as much as c++, just not a pure one.

Most do not really understand the use of that term 'object-oriented'.

In fact, an object can best be defined as: "a software machine allowing programs to access and modify a collection of data".

That means D is object-oriented - it's just that the module is THE object in D).

That translates to D treating the 'class' as a subordinate object (under the control of the module) - which is very different to C++, Java and C#.


> "Have a short learning curve for programmers comfortable with programming in C, C++ or Java."
> Gee, I wonder why?

I do not see large numbers of C++/Java/C# programmers, switching over to D anytime soon - particulary if they have a fondness towards object-oriented programming using classes.

But...I really *do* sympathise with your argument.. but, knowing what I know, you're better off using your mental energy on some other issue ;-)


> You didn't read the dip that I wrote did you? Nowhere in the dip did I change the concept of the modular unit. I just remove the one module per file Limination. That is it.

I actually found the dip draft confusing. After reading the justification at the start, for what was going to be proposed, and then reading what was actually proposed .. well.. to me, they don't seem to be entirely in sync with each other.

In any case, given the justification, I would replace the proposed solution to say .."Go use another language that (already) does what you want it to do".

If you have a fondness for classes, you will likely benefit from using another language ;-)

On 10/26/2018 12:45 PM, David Gileadi wrote:
> It certainly is deliberate, though.

Just to confirm, yes it is deliberate.

> I believe it may have been inspired by C++'s "friend" declarations.

That is correct, as well. C++ friend is a hackish thing, with consequences in appearance, name lookup and scope. Being able to declare a "friend" that is somewhere in some other file runs against notions of encapsulation.

Java's notion of one class per module is a bit too restrictive, as one may desire a set of closely interrelated classes that encapsulate a concept, and those should go into a module.

C++ files tend to be accumulations of lots of stuff, often unrelated. Translations of C++ code to D (such as dmd is) reflect that as well. Phobos suffers from that, too, it's hard to break away from it.

D modules should reflect a more encapsulated approach, which suggests an idiomatic D program should consist of a lot more, and smaller, modules than a typical C/C++ organization.

---

I spent a lot of time learning programming in the 80's on floppy disks. Files took a long time to look up and load, so one tended to organize a program as a smaller number of larger files. Such were faster to browse and faster to compile. These effects are insignificant today, but old habits linger.

On 27.10.18 05:20, Mike Parker wrote:
> If used to be that even if you moved the declaration of B to another module, then main would still have access to y through b. That was deemed to be a bug an is now deprecated.

That seems to make no sense at all (clearly main can access y though b by just implicitly casting to a superclass reference). Why was this done?

On Saturday, 27 October 2018 at 04:44:58 UTC, unprotected-entity wrote:
> On Saturday, 27 October 2018 at 02:49:00 UTC, 12345swordy wrote:
>>
>> D IS an object-oriented language as much as c++, just not a pure one.
>
> Most do not really understand the use of that term 'object-oriented'.
I don't know about you, but you are in a minority when it comes to that particular definition.

>> "Have a short learning curve for programmers comfortable with programming in C, C++ or Java."
>> Gee, I wonder why?
>
> I do not see large numbers of C++/Java/C# programmers, switching over to D anytime soon - particulary if they have a fondness towards object-oriented programming using classes.
It doesn't matter what you think. That is currently how D advertise itself right now.
I came from a c++ background with the promise that it is "better".
If you think this futile advertising then by all means create a new thread justifying your reasoning.
>> You didn't read the dip that I wrote did you? Nowhere in the dip did I change the concept of the modular unit. I just remove the one module per file Limination. That is it.
>
> I actually found the dip draft confusing. After reading the justification at the start, for what was going to be proposed, and then reading what was actually proposed .. well.. to me, they don't seem to be entirely in sync with each other.

This isn't helpful criticism at all. Can you be more specific?

> In any case, given the justification, I would replace the proposed solution to say .."Go use another language that (already) does what you want it to do".

LOL, sorry, but I didn't came here just for classes themselves. Programming in other language makes me miss D meta programming features.