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