On Saturday, 27 April 2024 at 13:11:22 UTC, Richard (Rikki) Andrew Cattermole wrote:
> 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.

ok. thanks for explaining. I would not a promote a change this will break existing code.

The point of private(this) is the option to use it, not to enforce it on anyone.

So in this case, we are in 'agreement' then ;-)

Still, if it were available, as an option, the programmer could then fix it themselves.

On Saturday, 27 April 2024 at 15:47:50 UTC, Arafel wrote:
> 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".

You are not the first to be 'surprised' by the reaction to such a simple, and sound idea.

Apart from the usual flamewares instigated by people in D who hate oop, think oo programmers are oop..philes, etc...etc.... the only real objection that I can fathom, is that in D, the module is the unit of encapsulation, not the class, and therefore if i use D, i need to think like that, and if I don't want to, then to bad for me.

I think that is the objection to which a debate is warranted.

Ignore all the other crap that always accompany's this idea. It has always been there, and will always be there.

The question is, does private(this) fundamentally change anything about D, or is it a minor change that would allow something that anyone who has ever written a class, be able to do in D. Or, do we accept that the class type must takes second place to the module (a non-type).

Swift is a great example of how both options (private and fileprivate) work together to solve programmers problems. They don't work against each other. The programmer can choose the option 'they think' is best for them. Swift does not try to coerce the programmer into thinking differently, unlike D.

Again, the idea is sound. It exists in practically all of the most widely used oo capable languages - even in OpenD. The change is simple. But the opposition is really fierce.

So anyone wanting or supporting this feature must be prepared to deal with that fierce opposition.  Most are not prepared to do that, hence the idea never progresses....

I am very comfortable challenging the statusquo ;-)

Some are (understandably), not.

Fortunately, we now have a forum group where the idea itself can be discussed. But even that is already proving to be difficult. Remember, the opposition to this is very fierce. So it really should not come as much of surprise ;-)

The D module is the unit of encapsulation, but it is NOT a type.

A class IS a type, and should have the necessary 'explicit' means to encapsulation those properties it wants to encapsulate. That is my argument. It really could not be simpler. It is certainly not an argument designed to provoke flame wars, as other would have you believe.

The most fundamental argument against it, is no, in D, a class doesn't need that option. .. because D already provides a means of encapsulation, the module, and that is sufficient... but if you really want a class that can have its own encapsulation properties, then put it in a module by itself.

So that last paragraph is the only opposition to it that is worthy of your attention.

Ignore all the other stuff ;-)

On Saturday, 27 April 2024 at 23:47:59 UTC, Warin Kempf wrote:
> On Saturday, 27 April 2024 at 13:10:08 UTC, Dukc wrote:
>> On Thursday, 25 April 2024 at 05:37:24 UTC, NotYouAgain 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.
>
> Yes because he instigated the last few wars.
>
> Its the only reason I hope Walter rejects this idea, seeing this guy lose his mind every 12 months is oddly amusing.

Actually, if you look at this post from Walter (on a seperate idea), well, I'm fundamentlly using the same logic as he is.

https://forum.dlang.org/post/v0h23q$1b89$1@digitalmars.com

That is, you can still programmer well with out private(this), sure, but  ..and then I'd use all most the exact logic in his arguements....

On Saturday, 27 April 2024 at 09:32:00 UTC, Jonathan M Davis wrote:
> .. .. - Jonathan M Davis

"but programmers can choose what makes the most sense for that particular class hierarchy, whereas we cannot possibly make that decision for all classes and not screw over developers in the process, because it's not one size fits all." https://forum.dlang.org/post/mailman.1555.1714097812.3719.digitalmars-d@puremagic.com

It would be great if that same reasoning of yours could be directed to this idea.

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

We can be friends, sure, but this unittest below is certainly not my friend ;-)

Yes, I know the solution you will come up with. Put these two classes in separate modules,
and make sure the unittest is not in the same module as Point;

D really is module-oriented-programming, not object-oriented-programming.

Its claim to support oop is rather dubious. One would need private(this) and protected(this), and then D could claim to support object-oriented-programming.

module m;
unittest
{
   import std;

   ColoredPoint c = new ColoredPoint(2, 4);

   writefln("%s : %s", c.x, c.y); // 2 : 4

   c.reset(); // actually this shouldn't even be allowed. It is not in the intent of the design.
   c.clear(); // only the clear() method should be using reset()

   writefln("%s : %s", c.x, c.y); // 0 : 0

}

class Point
{
  private int x, y;

  this(int x, int y)
  {
      this.x = x;
      this.y = y;
  };

  // the intent here, is that reset() be only callable from ColoredPoint.
  // but because protected is also public inside a module, there is
  // no way in D to 'declare' that intent.
  protected void reset() { this.x = 0; this.y = 0; }
}

class ColoredPoint : Point
{
    this(int x, int y)
    {
        super(x, y);
    };

    void clear() { reset(); }
}

On Sunday, 28 April 2024 at 20:49:37 UTC, Dukc wrote:
> On Sunday, 28 April 2024 at 00:16:37 UTC, NotYouAgain wrote:
>> On Saturday, 27 April 2024 at 13:10:08 UTC, Dukc wrote:
>>
>> A programmer being able to declare a private member in a class is a 'delicate' subject.
>>
>> It inflames war? Really?
>
> It's not so much that the subject itself would be touchy, bar for one person who just couldn't stop complaining over the status quo, to the point of resorting to sockpuppetry.
>
> It's that the arguments about it went so badly and fruitlessly, that I'm pretty sure people would hate to go over all that once again. Therefore, please don't start arguments on this.
>
>> But the idea is fundamentally sound.
>>
>> I simply cannot agree to those that say it is not sound.
>>
>> The motivations for such fierce opposition to it, is the problem.
>
> Unfortunately, you're doing the exact mistake I'm warning you about. By the time you're questioning motivations of others it's a sure sign you're not getting anywhere with this.
>
> This is the case *even if their motivations are actually problematic*. People aren't perfect. Maybe they deserve chastising about their attitudes, but it will still annoy them and destroy their respect for you and you proposal.
>
> It's not worth it. Anyone thinking it is should not be here in the first place.

Well I was clearly talking about the motivations of those people who hate oop and hate oop programmers and think they are oop..philes.

They need to be called out!

My motivation is clear and very simple.

Let D have the equivalant of Swift's 'private' and 'fileprivate'.

Currently D can only offer fileprivate (i.e. private).

Swift designers have already made the case for needing a distinction here.

At the moment, in D, every class if a module is effecitvely annotated with this hidden attribute:

@anything_else_in_this_module_is_a_c++_like_friend_to_this_class
class
{

}

I don't like it. I want to change it.

People objecting to the change simply because they hate oop and oop programmers, are the problem for why this idea can never be discuss in a civil manner.

The only valid objection relevant to the idea (so far), is that one can put each class and each unit test, all in their own module. That's a valid objection to be tackled in this discussion. My objection to that is clear. First, it only creates an illusion for oop. Second, it enforces a design constraint that should be left up to developers, and not the language.

Walters justification for fileprivate (ie. private), was to avoid the necessity for C++ friends. Fine. But now everything is a friend. I just want the explicit means to unfriend.

The idea is only controversial, because many in the D community are genuiely oop haters.

Once you understand that, you understand the pushback that is needed against them, when this idea is raised.

Also, the suggestion that idea should not be raised except once, is silly.

It should be raised as often as required, to determine whether it can gain necessary support to proceed to a DIP.

And calling me a socketpuppet because you think I'm the only one pursuing this idea, if not correct. Other people like the idea as well. Their posts are not my posts.

But thanks for distracting the discussion, once again.

On Sunday, 28 April 2024 at 20:49:37 UTC, Dukc wrote:
> ..
> ...

and as you can see, this confusion over D mis-use of the concept of oop private, has been around for a very long time ... long before I discovered D.

"One thing that is confusing in D is that private members of a type are accessible by the module that includes that type." (2012)

https://forum.dlang.org/post/ka1i21$29ac$1@digitalmars.com

On Sunday, 28 April 2024 at 20:49:37 UTC, Dukc wrote:
> ..
> ...

and look at the lengths one has to go to, to explain, and understand, what private in D means:

https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/

But if D has private(this), that article could have just been a one liner:

"If you need private to the class, use private(this)".

Done. Decades of confusion, useless converstations about it, all done away with.

You won't need that article for OpenD ;-)  .. just tell people to use private(this).

Now if anyone has the programming skills to submit a PR to OpenD for protected(this), please feel free to do so ;-)

And yes, this is 'campaign' - a campaign to be able to think about objects as being a unit of encapsulation (in addition to the module being a unit of encapsulation).

Then programmers can finally take control over D's mistake (to take that control away from them), and they can decide what is best for them .. just like they can do in Swift.

On Sunday, 28 April 2024 at 20:49:37 UTC, Dukc wrote:
> ..
> ....

anyway...

long live oop!

and see ya' all next time.

p.s - just remember to  annotate your class types in D, like this...

@anything_else_in_this_module_is_a_c++_like_friend_to_this_class
class
{

}