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

bachmeier no at spam.net
Thu Apr 25 20:57:29 UTC 2024


On Thursday, 25 April 2024 at 19:48:11 UTC, Jonathan M Davis 
wrote:
> On Wednesday, April 24, 2024 11:53:18 PM MDT Richard (Rikki) 
> Andrew Cattermole via dip.ideas wrote:
>> Apart from literature review type content, there isn't much to 
>> discuss here. There is nothing to tune.
>>
>> I suggest you start work on a draft DIP and move to 
>> development unless Walter or Atila have strong opinions 
>> against it.
>
> Well, Walter has consistently shot down requests for this kind 
> of feature in the past (and there was a discussion in the 
> newsgroup within just the past couple of months where it came 
> up IIRC, and Walter shot it down then), so unless someone can 
> come up with a really compelling reason why it's needed, it's 
> going to be shot down. Unless something has changed quite 
> recently, Walter's opinion on this has already been made quite 
> clear, and it's been the same for years.
>
> The normal answer is that if you really need the other code in 
> the module to not have access to the class' members, then that 
> class should just go in another module. In practice, the 
> current situation rarely causes problems. It seems more to be 
> something that annoys some folks on principle rather than being 
> an actual technical issue. I would be shocked if this DIP went 
> anywhere.
>
> - Jonathan M Davis

My understanding of the difference with this proposal is that it 
would leave the module as the unit of encapsulation, but it would 
add a second type of privacy. I don't know if that would convince 
Walter, but AFAICT, this change wouldn't lead to requests to add 
friend to the language.


More information about the dip.ideas mailing list