Javascript doesn't indicate much, it had no protection at all.

On Saturday, 27 April 2024 at 12:45:27 UTC, Kagamin wrote:
> Javascript doesn't indicate much, it had no protection at all.

ok sure. how about almost every other major language in use then.

but back to D...

class ClassWithPrivateField
{
  private int privateField; // actually, my intent here is private(this),
                            // but it cannot be expressed in D.
                            // guess I better put the subclass in its own module
                            // in the hope that someone thinks by doing that,
                            // I've expressed that intent.

  this() { this.privateField = 42;  }
}

class Subclass : ClassWithPrivateField
{
  private int subPrivateField;

  this()
  {
    this.subPrivateField = 23;
    this.privateField = 52; // is this a mistake? The compiler has no way to know.
  }
}

On Saturday, 27 April 2024 at 12:41:55 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 27/04/2024 9:18 PM, NotYouAgain wrote:
>> so, it seems, at least 2 problems indentified in this discussion, can now be solved with private(this).
>> 
>> 1 - It can (apparently) resolve an issue with synchronized classes (I' don't pretend to understand them)
>
> It does not resolve them.
>
> It enables a programmer who knows that an issue exists to prevent it.
> The same programmer who wrote that module.
>
> It could be solved by doing something like this internally and automatically. No need for a DIP exposing this capability.

but with private(this), the issue wouldn't exist in the first place.

Am I correct? (I'm not saying I am, I'm asking the question, since i don't know what synchronized classes are).

private(this) is for preventing issues from arising in the first place, not fixing them after they arise.

On 28/04/2024 1:02 AM, NotYouAgain wrote:
> On Saturday, 27 April 2024 at 12:41:55 UTC, Richard (Rikki) Andrew Cattermole wrote:
> 
>     On 27/04/2024 9:18 PM, NotYouAgain wrote:
> 
>         so, it seems, at least 2 problems indentified in this
>         discussion, can now be solved with private(this).
> 
>         1 - It can (apparently) resolve an issue with synchronized
>         classes (I' don't pretend to understand them)
> 
>     It does not resolve them.
> 
>     It enables a programmer who knows that an issue exists to prevent
>     it. The same programmer who wrote that module.
> 
>     It could be solved by doing something like this internally and
>     automatically. No need for a DIP exposing this capability.
> 
> but with private(this), the issue wouldn't exist in the first place.

If you use it.

There is plenty of code in existence that doesn't and the default isn't being suggested to be changed to require it (and would affect all classes, not just synchronized due to all having monitor objects).

In other words, it's not a fix.

On 27/4/24 15:10, Dukc wrote:
> I need to stress though, that you need to approach this subject with utmost diplomacy and humblety. Class-level |private| has been the very subject of more than one flame war in these forums. You will quickly become shunned if you're seen as instigating another one. The disclaimers you included at beginning of your post hint that you're already aware of that.

I have to say I have been surprised at how strongly some people react. I started by saying that I think it's a minor issue, has a workaround, and the workaround doesn't even feel too unusual to me. In short: I don't think it's worth raising a fuss, it's just one of those odd quirks that you learn to live with.

Still, I think it makes sense as a feature, and, honestly, I see it as a low-hanging fruit: it's an addition to the language, fully opt-in, it doesn't interact with pretty much anything else*, and has an already working implementation with even some real-life exposure to find out the rough edges.

So given that there are few drawbacks (I would dare say none beyond a very much hypothetical "complexity" in the language), and acknowledged, even if minor, benefits, the question for me becomes: "why not?".

"Because that's how things are" is something I can happily accept, as I have been doing so far, but not agree with.

*: Assuming you define it as: "for `private(this)` members or methods, code outside the class (or eventually struct) behaves as if it were in a different module".

On Sunday, 28 April 2024 at 00:07:22 UTC, NotYouAgain wrote:
> On Saturday, 27 April 2024 at 22:59:29 UTC, Steven Schveighoffer wrote:
>> On Friday, 26 April 2024 at 23:42:48 UTC, NotYouAgain wrote:
>>
>>> I don't agree with any of those propositions.
>>
>> OK, and that is understandable. What I'm trying to convey is that *this is a design decision*. You may not agree with it, but it is not something that I think is "fundamental" to OO programming.
>>
>> I don't need to continue this, I've said my piece, and I'm not interested in further discussion on this. If you end up with a more formal proposal I likely will argue against it, but no hard feelings, I fully understand that there are certain points of view that I don't agree with but that reasonable people will think is correct or better.
>>
>> We can agree to disagree, and still be friends ;)
>>
>> -Steve
>
> Actually, here is the fundamental problem:
>
> D won't let me expression my intent in the code below. Had I wanted to express a const or an immutable (for example) I can express it - D won't stand in my way there. But if I want to something that the vast majority of class-oriented oop programmers would expect to, that is, declare a member in my class-type to 'actually' be private to that type, then D and all the usual naysayers that come out when this topic is raised, insist on standing in my way. No they say. You actually don't need to do that. But if you do, put the subclass in separate module. Put the unittest in their separate module as well.
>
> So do you see the 'actual' problem here, or just the one you want to see?
>
> That there is so much fierce opposition to such a simple proposition, has always been bewildering. The source of that opposition, is usually a hate for oop in general, a hate for oo programmers (e.g calling them oop..philes), a wish to see oop stripped complelely out of D, or an insistence that all class-oriented oo programmers change how they think, so that think the way D wants to them think (a form of mind coercion really).
>
> The idea is that a class should have an option to have truly private member, is sound.
>
> The oppostition is the fundamental problem.

class ClassWithPrivateField
{
  private int privateField; // actually, my intent here is private(this),
                            // but it cannot be expressed in D.
                            // guess I better put the subclass in its own module
                            // in the hope that someone thinks by doing that,
                            // I've expressed that intent.

  this() { this.privateField = 42;  }
}

class Subclass : ClassWithPrivateField
{
  private int subPrivateField;

  this()
  {
    this.subPrivateField = 23;
    this.privateField = 52; // is this a mistake? The compiler has no way to know.
  }
}