On Wednesday, 22 June 2022 at 21:30:07 UTC, forkit wrote:
> On Wednesday, 22 June 2022 at 16:16:59 UTC, Dennis wrote:
>> On Wednesday, 22 June 2022 at 08:01:12 UTC, forkit wrote:
>>> [...]
>>
>> Here you go: https://github.com/dlang/dmd/pull/14238
>
> +1
>
> ballsy ;-)
>
> maxhaton's comment is interesting "I don't think I've ever actually seen a bug that would've been fixed by this."
>
> I refer maxhaton back to the seminal paper on the benefits of abstract data types:
>
> Programming with abstract data types - Liskov and Zilles 1974
>
> https://dl.acm.org/doi/pdf/10.1145/942572.807045

To which I ask again: Real example?

On Wednesday, 22 June 2022 at 21:25:44 UTC, forkit wrote:
> How crazy is that??!!!??!!

Your inability to present a single real life example is very strong evidence in itself that Max is right.

On Wednesday, 22 June 2022 at 22:47:11 UTC, max haughton wrote:
> On Wednesday, 22 June 2022 at 21:30:07 UTC, forkit wrote:
>> On Wednesday, 22 June 2022 at 16:16:59 UTC, Dennis wrote:
>>> On Wednesday, 22 June 2022 at 08:01:12 UTC, forkit wrote:
>>>> [...]
>>>
>>> Here you go: https://github.com/dlang/dmd/pull/14238
>>
>> +1
>>
>> ballsy ;-)
>>
>> maxhaton's comment is interesting "I don't think I've ever actually seen a bug that would've been fixed by this."
>>
>> I refer maxhaton back to the seminal paper on the benefits of abstract data types:
>>
>> Programming with abstract data types - Liskov and Zilles 1974
>>
>> https://dl.acm.org/doi/pdf/10.1145/942572.807045
>
> To which I ask again: Real example?

I don't get it.

You want evidence that abstract data types (types as defined by Liskov and Zilles) contribute to better program modularity? Isn't that self evident?

Isn't it also self-evident, that greater modularity leads to programs that can be better understood, modified, maintained, and proved correct?

You really need a 'real example' for this?

D requires you to think of the D module as being the overarching abstract data type. This results in the kind of design we typically see in D programming.

private(this) enables, and encourages, greater module-level modularity, enabling programmers to think more carefully about abstractions within the module itself.

private(this) enables the type protection that Liskov and Zilles talk about.

Without type protection, you're left with an immutable string that's only immutable as long as those using it (including the programmer), don't try to mutate it.

C'mon. I mean really. Are you seriously making an argument, that no benefit can come from 'private(this)'?

On Wednesday, 22 June 2022 at 21:30:07 UTC, forkit wrote:
> I refer maxhaton back to the seminal paper on the benefits of abstract data types:
>
> Programming with abstract data types - Liskov and Zilles 1974
>
> https://dl.acm.org/doi/pdf/10.1145/942572.807045

I wish you understood that every comment that you make where you fail to present any concrete instance of the problem caused weakens your case.

Assuming the people you are talking to are not well versed in the concept of asbtract data types is somewhat amusing, but I'm afraid, also playing against your case.

On Wednesday, 22 June 2022 at 23:07:19 UTC, forkit wrote:
> C'mon. I mean really. Are you seriously making an argument, that no benefit can come from 'private(this)'?

forkit, let me introduce you to the concept of burden of proof.

See, nobody has to make that case, so you have no need to strawman anyone. On the other hand, **YOU** have to make the case that there is a benefit.

Every message in this thread that fail to do so bury the case one foot deeper. Say hello to the moles from me, will you?

On Wednesday, 22 June 2022 at 23:08:38 UTC, deadalnix wrote:
> On Wednesday, 22 June 2022 at 21:30:07 UTC, forkit wrote:
>> I refer maxhaton back to the seminal paper on the benefits of abstract data types:
>>
>> Programming with abstract data types - Liskov and Zilles 1974
>>
>> https://dl.acm.org/doi/pdf/10.1145/942572.807045
>
> I wish you understood that every comment that you make where you fail to present any concrete instance of the problem caused weakens your case.
>
> Assuming the people you are talking to are not well versed in the concept of asbtract data types is somewhat amusing, but I'm afraid, also playing against your case.

But my case is simple. Really, really, really simple.

private(this) enables you to create an actual abstract data type, **within** the module.

That is, a type that "may be operated upon by the operations which define its abstract type".

Without private(this), it is just not possible to do this.

In essence, what can currently do in D, within a module, is declare an immutable string type that is immutable as long as those using it (elsewhere in the module) don't mutate it. That is not an abstract data type.

The benefits that arise from being able to use a real, enforceable, abstract data type *within* a module, are that it enables code within the module, to become more modular. Programmers now have the tool to make this possible!

Only good things can comes from this.

There is no downside to finer grained modularity, within a module.

If there is, can you provide a real world example please.

On Wednesday, 22 June 2022 at 23:12:04 UTC, deadalnix wrote:
> On Wednesday, 22 June 2022 at 23:07:19 UTC, forkit wrote:
>> C'mon. I mean really. Are you seriously making an argument, that no benefit can come from 'private(this)'?
>
> forkit, let me introduce you to the concept of burden of proof.
>
> See, nobody has to make that case, so you have no need to strawman anyone. On the other hand, **YOU** have to make the case that there is a benefit.
>
> Every message in this thread that fail to do so bury the case one foot deeper. Say hello to the moles from me, will you?

This is nonsense. I mean really.

The module itself is an abstract data type.

The benefits are obvious. Or is your argument, that D should get rid of modules?

All 'private(this)' does, is enable the opportunity for greater modularity *within* the module.

No evidence is required to back this up. Even a monkey brain should get it.