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