Extending D's support for object-oriented design with private(this)

NotYouAgain NotYouAgain at gmail.com
Fri Apr 26 11:36:32 UTC 2024


On Thursday, 25 April 2024 at 05:53:18 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> Apart from literature review type content, there isn't much to 
> discuss here. There is nothing to tune.
> ....

What literature review type content would you be expecting?

If i say the earth is round, to I need to cite literature?

If i say private class attributes are an important, widely used 
component for enhancing encapsulation, and all the benefits that 
flow from that; do I need to cite litereature for this?

The very purpose of the idea for private(this) is to have an 
easier to use mechanism for having class attributes that are 
private to the class 'within' a module, and having those 
attributes enforced by the compiler.

I don't think anyone is going to argue that class-oriented oop 
does not greatly benefit from having class attributes that can be 
private to the class ;-)

So what would an argument against this idea be exactly?

That D already offers you a harder way to do it, and you should 
just accept that?

i.e never put other code in a module, if the module has a class 
in it.
and never put a unittest in that module either.
then...and only then.. is your problem solved.

No. A harder way to do it, ensures programmers will not do it, 
and may not even both to use D.

D needs an easier way.

Please..please... someone come up with a different argument 
against this idea.

But in regards to literature, this is interesting (especially the 
AHF findings):

https://www.researchgate.net/publication/2478145_Toward_the_Design_Quality_Evaluation_of_Object-Oriented_Software



More information about the dip.ideas mailing list