• Manu (8/8) Oct 21 So, a great many class members tend to be `protected`... that's just how
• ryuukk_ (4/13) Oct 21 Sounds like a design issue on your end
• Max Samukha (7/9) Oct 21 I guess the answer would be: it's your package, so you control it
• Salih Dincer (8/11) Oct 21 Yes. There is no such thing as hiding the facilities inside a
• Atila Neves (4/15) Oct 22 My guess is the story is that nobody needed/wanted that before.
• Kagamin (10/10) Oct 23 In C# it's known as `protectedinternal` access. The idea is to
• Kagamin (18/18) Oct 23 Another option is an accessor class:

Manu <turkeyman gmail.com> writes:

So, a great many class members tend to be `protected`... that's just how
classes are.
We also avoid `friend` in D with `package`, which I find to often be quite
useful.

The trouble is... in a high number of cases where I want to make something
`package`, it ALSO should be `protected`, but these 2 are mutually
exclusive.

This is a problem. We need a way to express both... what's the story here?

ryuukk_ <ryuukk.dev gmail.com> writes:

On Monday, 21 October 2024 at 07:49:18 UTC, Manu wrote:
 So, a great many class members tend to be `protected`... that's 
 just how
 classes are.
 We also avoid `friend` in D with `package`, which I find to 
 often be quite
 useful.

 The trouble is... in a high number of cases where I want to 
 make something `package`, it ALSO should be `protected`, but 
 these 2 are mutually exclusive.

Sounds like a design issue on your end

If it is hidden, it doesn't need to be abstracted

You don't need OOP

Max Samukha <maxsamukha gmail.com> writes:

On Monday, 21 October 2024 at 07:49:18 UTC, Manu wrote:

 This is a problem. We need a way to express both... what's the 
 story here?

I guess the answer would be: it's your package, so you control it 
and don't need to protect it from yourself. At least, that was 
part of the argument against class-private (as I understood it): 
the module is the API boundary, why would you protect anything 
inside? Ironically, packages are not sealed, so 'package' doesn't 
really protect anything at all.

Salih Dincer <salihdb hotmail.com> writes:

On Monday, 21 October 2024 at 07:49:18 UTC, Manu wrote:
 
 This is a problem. We need a way to express both... what's the 
 story here?

Yes. There is no such thing as hiding the facilities inside a 
module from each other in D. It may seem strange when compared to 
languages ​​like C++, but it actually reveals the practical side 
of D: Why shouldn't a programmer be able to access the facilities 
inside a module while working in it? Who are we protecting from 
whom?

SDB 79

Atila Neves <atila.neves gmail.com> writes:

On Monday, 21 October 2024 at 07:49:18 UTC, Manu wrote:
 So, a great many class members tend to be `protected`... that's 
 just how
 classes are.
 We also avoid `friend` in D with `package`, which I find to 
 often be quite
 useful.

 The trouble is... in a high number of cases where I want to 
 make something `package`, it ALSO should be `protected`, but 
 these 2 are mutually exclusive.

 This is a problem. We need a way to express both... what's the 
 story here?

My guess is the story is that nobody needed/wanted that before. 
I'm struggling to understand what the use case would be; I would 
love to know what design led to this situation.

Kagamin <spam here.lot> writes:

have a protected member, but also access it across a package. A 
workaround is to have an accessor:
```
class A
{
	protected int b;
	final package int b2(){ return b; }
}
```

Kagamin <spam here.lot> writes:

Another option is an accessor class:
```
class A
{
	protected int b;
	package class Accessor
	{
		int b(){ return this.outer.b; }
	}
}

void f1()
{
	A a=new A;
	a.b=2;
	auto aa=a.new Accessor;
	assert(aa.b==2);
}
```