On 8/6/22 12:00, bauss wrote:
> 
> I completely agree. I really hate the current design, because I have been in situations where I have separated classes because they needed private fields, but then later I actually needed some of the fields shared and had to share those fields public.

Out of curiosity, why wasn't `package` or eventually `package(foo)` [1] an option? It seems to have been designed for this very purpose.

Of course the classes could be in packages with no common ancestor, but then it would perhaps be worth questioning how so closely coupled classes end up so far away in the hierarchy.

[1]: https://dlang.org/spec/attribute.html#VisibilityAttribute

On Wednesday, 8 June 2022 at 10:30:59 UTC, Ola Fosheim Grøstad wrote:
>
> They would also ask what "private class" means.

That's easy to solve ;-)

It's simple. People will know if its documented (I mean how else do they know, that private is not really private - cause it says so in the documentation - or they discover it by mistake (more likely).

A really minor change to the existing documentation, as such, and it's done:

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

1. Visibility is an attribute that is one of private, private (this), package, protected, public, or export. They may be referred to as protection attributes in documents predating DIP22.

2. Symbols with private visibility can only be accessed from within the same module. Symbols with private (this) visibility can only be accessed from within the abstraction in which it is defined, and can be applied to a class or struct only.

On Wednesday, 8 June 2022 at 10:49:58 UTC, Arafel wrote:
> On 8/6/22 12:00, bauss wrote:
>> 
>> I completely agree. I really hate the current design, because I have been in situations where I have separated classes because they needed private fields, but then later I actually needed some of the fields shared and had to share those fields public.
>
> Out of curiosity, why wasn't `package` or eventually `package(foo)` [1] an option? It seems to have been designed for this very purpose.
>
> Of course the classes could be in packages with no common ancestor, but then it would perhaps be worth questioning how so closely coupled classes end up so far away in the hierarchy.
>
> [1]: https://dlang.org/spec/attribute.html#VisibilityAttribute

Because functions cannot be package __and__ virtual.

On Wednesday, 8 June 2022 at 10:30:59 UTC, Ola Fosheim Grøstad wrote:
>
> Anything simple is better than @keyword, private(this), private class etc. Such syntax screams "amateur project" and I wouldn't even consider downloading a language like that. When I first tried D it was because the syntax looked clean (way before the @madness caught on).

It can't be: 'private this()' because that conflicts with the use of the word 'this' that is associated with a constructor.

'private (this)' makes perfect sense to me.

First, the word 'this' is already associated  "to the object, class, or other entity of which the currently running code is a part." - https://en.wikipedia.org/wiki/This_(computer_programming)

Second. The exact same syntax can be used for class or struct.

One could argue that 'private (this)' and 'private this()' are too close syntactically, and could cause confusion. I wouldn't disagree. But I'd be fine with it, since I'd be using it so often, it'll be programmed into my muscle memory ;-)

On Wednesday, 8 June 2022 at 11:02:45 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 8 June 2022 at 10:30:59 UTC, Ola Fosheim Grøstad wrote:
>> They would also ask what "private class" means. If you are gonna do it, do at least propose a proper keyword for it: local, hidden, internal…
>
> Btw, the original OOP syntax from Simula is **HIDDEN** and **PROTECTED**. So there is some precedent for this.

I wouldn't object to 'hidden int x'.

This would solve the problem of 'private (this)' and 'private this()' being too close syntactically.

On 8/6/22 12:58, bauss wrote:
> Because functions cannot be package __and__ virtual.

Good reason, indeed. Well, I guess it technically can, if all your subclasses are in the same package (or at least branch). Agreed, not too useful in the general case, though.

Would it make sense however to make `protected` behave like it does in java [1], and include `package` visibility? Given that AFAIK D took most of its OOP ideas from Java, I think it wouldn't be too far-fetched.

Perhaps another option would be to add an optional parameter like `package` already does to activate this functionality, or to just allow both keywords: `protected package`.


[1]: https://docs.oracle.com/javase/specs/jls/se18/html/jls-6.html#jls-6.6.2

On Wednesday, 8 June 2022 at 13:11 forkit via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 8 June 2022 at 11:02:45 UTC, Ola Fosheim Grøstad wrote:
> > On Wednesday, 8 June 2022 at 10:30:59 UTC, Ola Fosheim Grøstad wrote:
> >> They would also ask what "private class" means. If you are gonna do it, do at least propose a proper keyword for it: local, hidden, internal…
> >
> > Btw, the original OOP syntax from Simula is **HIDDEN** and **PROTECTED**. So there is some precedent for this.
>
> I wouldn't object to 'hidden int x'.
>
> This would solve the problem of 'private (this)' and 'private
> this()' being too close syntactically.

Or copy delphi and use 'strict private' (and 'strict protected').

On Wednesday, 8 June 2022 at 11:18:42 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 8 June 2022 at 11:07:39 UTC, forkit wrote:
>> I wouldn't object to 'hidden int x'.
>
> It is at least easy to understand.
>
>
> (Simula had "hidden", "protected" and "hidden protected" (private), but that doesn't matter ;-)

Interesting that Scala has 'private[this]'

https://stackoverflow.com/questions/9698677/privatethis-vs-private

Still, I think I'd prefer 'hidden' actually. It's pretty clear what you're stating here with that word. And, you can't confuse it with a contructor like 'this()'.

But it would require the addition of a new keyword, which takes the idea to a whole new level :-(

The addition of new keyword is really something I'd want to avoid, if at all possible.

perhaps 'private class' and 'private struct' makes more sense after all.