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

NotYouAgain NotYouAgain at gmail.com
Sun Apr 28 23:32:45 UTC 2024


On Sunday, 28 April 2024 at 20:49:37 UTC, Dukc wrote:
> On Sunday, 28 April 2024 at 00:16:37 UTC, NotYouAgain wrote:
>> On Saturday, 27 April 2024 at 13:10:08 UTC, Dukc wrote:
>>
>> A programmer being able to declare a private member in a class 
>> is a 'delicate' subject.
>>
>> It inflames war? Really?
>
> It's not so much that the subject itself would be touchy, bar 
> for one person who just couldn't stop complaining over the 
> status quo, to the point of resorting to sockpuppetry.
>
> It's that the arguments about it went so badly and fruitlessly, 
> that I'm pretty sure people would hate to go over all that once 
> again. Therefore, please don't start arguments on this.
>
>> But the idea is fundamentally sound.
>>
>> I simply cannot agree to those that say it is not sound.
>>
>> The motivations for such fierce opposition to it, is the 
>> problem.
>
> Unfortunately, you're doing the exact mistake I'm warning you 
> about. By the time you're questioning motivations of others 
> it's a sure sign you're not getting anywhere with this.
>
> This is the case *even if their motivations are actually 
> problematic*. People aren't perfect. Maybe they deserve 
> chastising about their attitudes, but it will still annoy them 
> and destroy their respect for you and you proposal.
>
> It's not worth it. Anyone thinking it is should not be here in 
> the first place.

Well I was clearly talking about the motivations of those people 
who hate oop and hate oop programmers and think they are 
oop..philes.

They need to be called out!

My motivation is clear and very simple.

Let D have the equivalant of Swift's 'private' and 'fileprivate'.

Currently D can only offer fileprivate (i.e. private).

Swift designers have already made the case for needing a 
distinction here.

At the moment, in D, every class if a module is effecitvely 
annotated with this hidden attribute:

@anything_else_in_this_module_is_a_c++_like_friend_to_this_class
class
{

}

I don't like it. I want to change it.

People objecting to the change simply because they hate oop and 
oop programmers, are the problem for why this idea can never be 
discuss in a civil manner.

The only valid objection relevant to the idea (so far), is that 
one can put each class and each unit test, all in their own 
module. That's a valid objection to be tackled in this 
discussion. My objection to that is clear. First, it only creates 
an illusion for oop. Second, it enforces a design constraint that 
should be left up to developers, and not the language.

Walters justification for fileprivate (ie. private), was to avoid 
the necessity for C++ friends. Fine. But now everything is a 
friend. I just want the explicit means to unfriend.

The idea is only controversial, because many in the D community 
are genuiely oop haters.

Once you understand that, you understand the pushback that is 
needed against them, when this idea is raised.

Also, the suggestion that idea should not be raised except once, 
is silly.

It should be raised as often as required, to determine whether it 
can gain necessary support to proceed to a DIP.

And calling me a socketpuppet because you think I'm the only one 
pursuing this idea, if not correct. Other people like the idea as 
well. Their posts are not my posts.

But thanks for distracting the discussion, once again.


More information about the dip.ideas mailing list