June 13, 2022

On Monday, 13 June 2022 at 09:09:08 UTC, user1234 wrote:

>

On Monday, 13 June 2022 at 08:13:14 UTC, claptrap wrote:

>

On Sunday, 12 June 2022 at 14:05:00 UTC, Max Samukha wrote:

>

On Sunday, 12 June 2022 at 11:47:53 UTC, Mike Parker wrote:

>

Hi. My name's Mike. Nice to meet you.

Hi, Mike! Congratulations on being the first unsurprised D user! (You were actually surprised for a moment, weren't you?)

Anyone who used Object Pascal / Delphi wouldn't have been surprised either.

True but ObjFPC has strict private too since a while: demo.
This does exactly what is discussed on the D forum since a week.

well the online compilers are too old, but if you try this code with a more recent compiler

{$MODE OBJFPC}{$H+}
{$MODESWITCH ADVANCEDRECORDS}
type TS = record
  private
    a: integer;
  strict private
    b: integer;
end;

var
 s: TS;

begin
  s.a := 1; // OK
  s.b := 1; // NG
end.

this gives

>

project1.lpr(15,5) Error: identifier idents no member "b"

June 13, 2022
On Monday, 13 June 2022 at 09:05:43 UTC, Mike Parker wrote:
>
> I don't get why you expect it to work. If you declare `Bar` outside of the module, then how could you access the private members of `Foo` through a `Bar`? It works in the same module because... private to the module.

Because Bar inherits from Foo, Foo is in a, thus it should be as following:

Outside of the module Foo resides in:

- Only public members are accessible.

Inside the module Foo resides in:

- All members are accessible.

That's the whole point of module private, that you can access private members within a module regardless of where they reside, as long as you're in the module the symbol belongs to.

In this case _c belongs to the module a, so we should always be able to access _c within the module.

If D wasn't module private, then I wouldn't expect it to work, but since D states itself to be module private then I expect it to work because:

Bar inherits Foo, _c is a member of Foo, but also private to the module of Foo.

When we access Bar within the module of Foo, then all members of Foo should be accessible.

When we access Bar outside of the Foo's module, then only public members of Foo should be accessible.

This should always be true with module private, it wouldn't be true with class private.

So either D needs to admit it's not truly module private or it needs to fix that.
June 13, 2022

On Monday, 13 June 2022 at 09:11:42 UTC, Ola Fosheim Grøstad wrote:

>

It follows from the principles of inheritance. A Bar is a more detailed Foo. If you cannot interact with a Bar as you would with a Foo, then Bar is breaking with the core principles of inheritance

No, it does not follow in this case. A subclass does not have access to the private members of the superclass in D unless they are declared in the same module. So what that code is doing is saying, "Hey Bar, give me this field that you don't have access to."

June 13, 2022
On Monday, 13 June 2022 at 07:59:24 UTC, bauss wrote:
>
> ....
> D states it is "module private" but really it is neither "module private" or "class private" it's a mix between the two... and I'm not sure whether that's good or not.

on the issue of 'good or bad', well the answer is subjective.

It depends on what you want, and expect.


// ----
module test;
@safe:

import std;

void myFunc()
{
    int a = 100; // a is bound (private) to scope, not module
                 // so = good, I wanted and expected this.
}

class foo
{
    static private int b = 200; // b is bound to module scope
                                // even though I thought I was binding it to local scope
                                // This is not what I wanted or expected.
                                // so module global = bad.
}

class bar
{
    static private(module) int c = 300; // c is bound to module scope
}                                       // good, that's what I wanted and expected.

void main()
{
    writeln(a); // won't compile = good

    writeln(foo.b); // will compile = bad.
                    // bad cause compiler has no idea what i wanted,
                    // cause i can't tell it what I wanted.
                    // there is no feature in D to do this.

   writeln(bar.c); // will compile = good. It's what I wanted and expected.
}

// --------
June 13, 2022

On Monday, 13 June 2022 at 09:34:46 UTC, Mike Parker wrote:

>

No, it does not follow in this case. A subclass does not have access to the private members of the superclass in D unless they are declared in the same module. So what that code is doing is saying, "Hey Bar, give me this field that you don't have access to."

It wasn't the subclass that tried to access, it was the owner of the subclass, the module.

If the owner of Cyborgs have direct access to the brain that all Cyborgs possess, then it follows that it also must have direct access to the brain of PinkCyborgs too without having to call it a Cyborg. A PinkCyborg is also a Cyborg.

If a surgeon can operate directly on the brain of a Human, then it follows that he also should be able to operate directly on the brain of Men and Women, without having to claim that they are just Humans to him (and that he does not care about their gender specific attributes). Men and Women are undeniably Human. It should not matter whether the Ambulance personell says "this is a Man" or "this is a Human".

June 13, 2022

On Monday, 13 June 2022 at 10:03:59 UTC, Ola Fosheim Grøstad wrote:

>

On Monday, 13 June 2022 at 09:34:46 UTC, Mike Parker wrote:

>

No, it does not follow in this case. A subclass does not have access to the private members of the superclass in D unless they are declared in the same module. So what that code is doing is saying, "Hey Bar, give me this field that you don't have access to."

It wasn't the subclass that tried to access, it was the owner of the subclass, the module.

Typo: "it was the owner of the super class, the module."

June 13, 2022

On Monday, 13 June 2022 at 10:03:59 UTC, Ola Fosheim Grøstad wrote:

>

It wasn't the subclass that tried to access, it was the owner of the subclass, the module.

Through the subclass.

>

If the owner of Cyborgs
If a surgeon can operate

I'm a Parker. My father is a Parker. But if you ask me for the contents of my father's safe, and I don't have the combination, then you aren't getting the contents of my father's safe. Ask me to put you in touch with my father though, and you can work something out.

It's all about the interface here. An instance of B is an A only in terms of the public (and protected) interface. It doesn't have access to A's private members if it isn't declared in the same module, so you can't get A's private members through an instance of B. You have to cast to A.

This doesn't allow access either:

module ca;

import cb;

class A {
    private int _x;

    protected void modX(B b) {
        b._x = 10;
    }
}

---

module cb;

import ca;

class B : A {
    void setX() { modX(this); }
}

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

June 13, 2022

On Monday, 13 June 2022 at 10:13:30 UTC, Mike Parker wrote:

>

On Monday, 13 June 2022 at 10:03:59 UTC, Ola Fosheim Grøstad wrote:

>

It wasn't the subclass that tried to access, it was the owner of the subclass, the module.

Through the subclass.

No. You have direct access.

> >

If the owner of Cyborgs
If a surgeon can operate

I'm a Parker. My father is a Parker. But if you ask me for the contents of my father's safe, and I don't have the combination, then you aren't getting the contents of my father's safe. Ask me to put you in touch with my father though, and you can work something out.

This is not an example of inheritance. Inheritance is a subtyping relation.

If you let the Surgeon module own the Human blueprint and direct access to all the brains of all Humans, then it follows that the Surgeon module has to be given direct access to all Humans whether you know if that Human also is a Woman or not.

Keep in mind that there are no pure Humans in the real world, only Men or Women (or some other gendered variations). The fact that we can instance Humans does not mean that they are not Women or Men. It means that we don't care (or know) whether they are Women or Men when we give them a computer representation.

June 13, 2022

On Monday, 13 June 2022 at 10:13:30 UTC, Mike Parker wrote:

>

Look, I'm not against the logic, I completely understand it from the perspective of that a subclass shouldn't have access to private members of the class it inherits from, BUT remember in D private doesn't mean private to the class, so the symbol should only be private when accessed from anywhere but the module.

June 13, 2022

On Monday, 13 June 2022 at 10:43:09 UTC, bauss wrote:

>

On Monday, 13 June 2022 at 10:13:30 UTC, Mike Parker wrote:

>

Look, I'm not against the logic, I completely understand it from the perspective of that a subclass shouldn't have access to private members of the class it inherits from, BUT remember in D private doesn't mean private to the class, so the symbol should only be private when accessed from anywhere but the module.

To add on to this; it's not a matter of what's more logical, but simply that D is contradicting itself, so either D stops being referred to as "module private" or this will be deemed an unfinished feature/bug.