Extending D's support for object-oriented design with private(this)
NotYouAgain
NotYouAgain at gmail.com
Tue Apr 30 09:56:56 UTC 2024
On Monday, 29 April 2024 at 08:34:21 UTC, Dukc wrote:
> ..
> Too bad, as it leads me to the conclusion you're not worth
> debating the DIP with until you learn to be less combative.
> Sooner or later other people will conclude the same - probably
> some have done so already.
> ...
but that was surely the intention of some who inserted themselves
into this discussion wasn't it? i.e. to make it combative ... and
turn people off..
That's not an unusual stratedy to employ.
It's been used before, and it'll be used again, especially with
this idea.
If it were up to me, I would make 'private' mean private, and
would add fileprivate to D.
Everyone would need to change 'private' in the code base to
'fileprivate' of course.
If that broke anything in their code base, then it almost
certainly should do just that, as it would indicate some pretty
dogdy programming practices going on - which is exactly what
private to the module does - and even more so when there is NO
true private.
So maybe my next DIP idea will be: change 'private' to mean what
everyone expects it to 'mean', and add 'fileprivate' (to work as
private currently does) - just like Swift did, and fully
succeeded in doing by the way.
But do think that will be less or more controversial?
More information about the dip.ideas
mailing list