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