Preparing for the New DIP Process (page 8)

On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote:
> On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote:
>> On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote:
>>> On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote:
>>>>
>>>> * establish support for fleshing out ideas before a DIP is even written
>>>>
>>>
>>> It's 2024. That should have been the principle a decade ago
>>>
>>> Remember how the so called 'discussions' about the 'privateThis' concept always got heaped on. People just wanted to shut it down rather that discuss it. 'Go write a DIP' was the response...remember.
>>
>> The class vs module level of encapsulation was fleshed out a lot in the forums awhile back. I think it's fair to say most people where happy (or neutral) with the status quo, and were not convinced by the pro-class-level arguments.
>>
>> I also suspect those that did prefer class level private (I believe this is what Atila prefers), it's not high on their list of priorities.
>
> I like private as it is now. Especially because if anyone wants it to be "class-private", they can do that anyway: write a class per module like one has to in Java.
>
> My 2 centimes (cos I live in Switzerland) is that if you're worried about too much code having access to your private functions, your module is probably too large.

OpenD has already merged this into master anyway. So people can finally decided for themselves, rather than being told they don't need it and here's a workaround in case you do.

Btw. no DIP was required.

So if anyone wants an 'option' for "class-private", they can now do it in OpenD, and the this topic/debate is should be well and truly over. Just like const, @safe, ....etc... private(this) is there to use when your usecase requires as such. No effect on existing D code whatsoever.

FairEnough

On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote:
> ..
> My 2 centimes (cos I live in Switzerland) is that if you're worried about too much code having access to your private functions, your module is probably too large.

I'd argue:
 (1) this module is not too large. (sure its just for demo the concept though)
 (2) private(this) make complete sense here. There is zero need for the unittest of have access to count. So why not make that part of the Widget class design. I don't see any downside whatsoever. Is it absolutely necessary, well, no. But I like the design clarity it offers.

module test;

class Widget
{
  public:
    this() { ++count; }
    ~this() { --count; }

    int numWidgets(){ return count; }

  private(this):
    static int count;
};

unittest
{
    Widget w = new Widget, x = new Widget;
    assert(w.numWidgets() == 2);
}

mate

On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote:
> I like private as it is now. Especially because if anyone wants it to be "class-private", they can do that anyway: write a class per module like one has to in Java.
>
> My 2 centimes (cos I live in Switzerland) is that if you're worried about too much code having access to your private functions, your module is probably too large.

To get peace from the forum troll, it might be worth it to add a compiler switch `-privateToTheClass` which errors out when it finds more than one class per file.

Mike Parker

Posted in reply to mate

On Tuesday, 30 January 2024 at 00:06:26 UTC, mate wrote:
> On Monday, 29 January 2024 at 12:34:05 UTC, Atila Neves wrote:
>> I like private as it is now. Especially because if anyone wants it to be "class-private", they can do that anyway: write a class per module like one has to in Java.
>>
>> My 2 centimes (cos I live in Switzerland) is that if you're worried about too much code having access to your private functions, your module is probably too large.
>
> To get peace from the forum troll, it might be worth it to add a compiler switch `-privateToTheClass` which errors out when it finds more than one class per file.

Let's shut this down please. Thanks.