`restricted` member variables

forkit forkit at gmail.com
Wed Jun 22 23:21:17 UTC 2022


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.



More information about the Digitalmars-d mailing list