On 10/27/18 7:40 AM, Timon Gehr wrote:
> 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?

Read the bug report:

https://issues.dlang.org/show_bug.cgi?id=15897

-Steve

On 10/26/18 5:30 PM, 12345swordy 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!!!

You mean why are they present in the class instance? That's basic inheritance, no?

If that wasn't the case, then you'd have serious issues:

class C
{
   private int x;
   void increment() {++x;}
}

class B : C {}

void main()
{
   auto b = new B;
   b.increment();
}

If b didn't have an `x` in it, then how would this work?

Again, I feel like there is a misunderstanding.

> Do I need to write a DIP for you guys to understand what the hell I am talking about!?

I don't think writing the same words in another place is going to make them more understandable.

-Steve

On Saturday, 27 October 2018 at 14:20:10 UTC, Steven Schveighoffer wrote:
>
> If b didn't have an `x` in it, then how would this work?
>

Only in D, does b have x in it.

In C++, Java and C#, b does *not* have x in it.

On 10/27/18 11:24 AM, unprotected-entity wrote:
> On Saturday, 27 October 2018 at 14:20:10 UTC, Steven Schveighoffer wrote:
>>
>> If b didn't have an `x` in it, then how would this work?
>>
> 
> Only in D, does b have x in it.
> 
> In C++, Java and C#, b does *not* have x in it.
> 

This isn't correct. I'd write examples in each of those languages, but don't have the time right now.

-Steve

On Saturday, 27 October 2018 at 15:24:19 UTC, unprotected-entity wrote:
> Only in D, does b have x in it.
>
> In C++, Java and C#, b does *not* have x in it.

Well, they have it, it is just an error to use it from there.

On Saturday, 27 October 2018 at 15:24:19 UTC, unprotected-entity wrote:
> On Saturday, 27 October 2018 at 14:20:10 UTC, Steven Schveighoffer wrote:
>>
>> If b didn't have an `x` in it, then how would this work?
>>
>
> Only in D, does b have x in it.
>
> In C++, Java and C#, b does *not* have x in it.

It might be that you're confusing "have" to mean "has access". In other languages b doesn't have access to x, but it most definitely has an x inside of it.

On Saturday, October 27, 2018 12:06:36 PM MDT Atila Neves via Digitalmars-d wrote:
> On Saturday, 27 October 2018 at 15:24:19 UTC, unprotected-entity
>
> wrote:
> > On Saturday, 27 October 2018 at 14:20:10 UTC, Steven
> >
> > Schveighoffer wrote:
> >> If b didn't have an `x` in it, then how would this work?
> >
> > Only in D, does b have x in it.
> >
> > In C++, Java and C#, b does *not* have x in it.
>
> It might be that you're confusing "have" to mean "has access". In other languages b doesn't have access to x, but it most definitely has an x inside of it.

And depending on the language, you can even give access to them - e.g. in C++, friends could be used to give access, though it would be a bit odd, since normally you'd just used protected for such a use case rather than making the derived class a friend. Either way, Derived classes _are_ base classes and literally contain their base class members. They wouldn't work when used via a pointer of the base class type otherwise. So, yeah, it's a question of having access and not whether they're there. They have to be there. The combination of D's private being private to the module, not the class, and putting the derived class in the same module as the base class simply creates a situation that you wouldn't normally get in other languages with regards to access. The layout of the class itself should actually be very similar to what you'd get in C++, Java, C#, etc. Each language may have minor differences in how it actually lays out classes, but the fact that a base class is physically part of a derived class is common to all of them, and unless the language requires that all base classes be pure interfaces, I don't see how it could possibly be otherwise.

- Jonathan M Davis

On Saturday, 27 October 2018 at 18:06:36 UTC, Atila Neves wrote:
> On Saturday, 27 October 2018 at 15:24:19 UTC, unprotected-entity wrote:
>> On Saturday, 27 October 2018 at 14:20:10 UTC, Steven Schveighoffer wrote:
>>>
>>> If b didn't have an `x` in it, then how would this work?
>>>
>>
>> Only in D, does b have x in it.
>>
>> In C++, Java and C#, b does *not* have x in it.
>
> It might be that you're confusing "have" to mean "has access". In other languages b doesn't have access to x, but it most definitely has an x inside of it.

In C++/Java/C#, x is private to C, as you would expect, since it was declared private to C.

In D, it's not private to C, or anything else in the same module.

I know the reasoning behind this, but it's just awful, and invites bugs into your code.

oh... so you accidently typed b.x++ in main().. or someother code outside of the class), instead of b.increment() ...well...to bad.

Yes.. it's an old discussion, I know..but an unprotected entity is a useless programming construct, and will invite bugs into your program.

On Saturday, October 27, 2018 10:38:53 PM MDT unprotected-entity via Digitalmars-d wrote:
> On Saturday, 27 October 2018 at 18:06:36 UTC, Atila Neves wrote:
> > On Saturday, 27 October 2018 at 15:24:19 UTC,
> >
> > unprotected-entity wrote:
> >> On Saturday, 27 October 2018 at 14:20:10 UTC, Steven
> >>
> >> Schveighoffer wrote:
> >>> If b didn't have an `x` in it, then how would this work?
> >>
> >> Only in D, does b have x in it.
> >>
> >> In C++, Java and C#, b does *not* have x in it.
> >
> > It might be that you're confusing "have" to mean "has access". In other languages b doesn't have access to x, but it most definitely has an x inside of it.
>
> In C++/Java/C#, x is private to C, as you would expect, since it was declared private to C.
>
> In D, it's not private to C, or anything else in the same module.
>
> I know the reasoning behind this, but it's just awful, and invites bugs into your code.
>
> oh... so you accidently typed b.x++ in main().. or someother code
> outside of the class), instead of b.increment() ...well...to bad.
>
> Yes.. it's an old discussion, I know..but an unprotected entity is a useless programming construct, and will invite bugs into your program.

LOL. I have no clue how you just accidentally use a member variable. But if that's a concern, it's exactly the same concern that you would have in C++ or Java from within a functions inside a class that you don't want accessing a particular member variable. D just puts the demarcation line at the module instead of the class. It doesn't really change much ultimately in terms of needing to being aware of what is supposed to be accessed where for anything that has access. And if you want to further restrict access, then put classes in their own modules. Problem solved. Some of the languages that define private the way that some folks want already require that anyway. Honestly, I have _never_ seen a bug caused by the fact that D makes private restrict access to the module level and not the class or struct level. From everything I've seen, this is entirely an issue of people not liking the idea and not something that's an actual problem in practice.

- Jonathan M Davis

On 28/10/2018 6:11 PM, Jonathan M Davis wrote:
> Honestly, I have_never_  seen a bug caused by the fact that D makes private
> restrict access to the module level and not the class or struct level. From
> everything I've seen, this is entirely an issue of people not liking the
> idea and not something that's an actual problem in practice.

Which is why when we have "anonymous" people posting these, we tend to not reply to them. It does not lead to useful discussions for anyone.