Menu
Search

Forums

Forum Index

Thread overview
package & protected?
Oct 21
Manu
Oct 21
ryuukk_
Oct 23
Kagamin
Oct 23
Kagamin
October 21
Gravatar of ManuPosted by ManuReply
Manu
Gravatar of Manu
Attachments:


Reply
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?
October 21
Gravatar of ryuukk_Posted by ryuukk_
in reply to Manu		Reply
ryuukk_
Gravatar of ryuukk_
Posted in reply to Manu


Reply
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
October 21
Gravatar of Max SamukhaPosted by Max Samukha
in reply to Manu		Reply
Max Samukha
Gravatar of Max Samukha
Posted in reply to Manu


Reply
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.
October 21
Gravatar of Salih DincerPosted by Salih Dincer
in reply to Manu		Reply
Salih Dincer
Gravatar of Salih Dincer
Posted in reply to Manu


Reply

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

October 22
Gravatar of Atila NevesPosted by Atila Neves
in reply to Manu		Reply
Atila Neves
Gravatar of Atila Neves
Posted in reply to Manu


Reply
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.
October 23
Gravatar of KagaminPosted by Kagamin
in reply to Atila Neves		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to Atila Neves


Reply

In C# it's known as protectedinternal access. The idea is to 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; }
}
October 23
Gravatar of KagaminPosted by Kagamin
in reply to Kagamin		Reply
Kagamin
Gravatar of Kagamin
Posted in reply to Kagamin


Reply

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);
}