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