June 20, 2022
On Monday, 20 June 2022 at 08:25:34 UTC, forkit wrote:
> On Sunday, 19 June 2022 at 22:45:44 UTC, forkit wrote:
>>[...]
>
> I'm happy (more than happy actually) to conclude my input into this discusssion with this:
>
> [...]

Then draft a DIP to get the ball rolling.
But you won't.
June 20, 2022

On Saturday, 18 June 2022 at 18:02:08 UTC, Max Samukha wrote:

>

On Saturday, 18 June 2022 at 08:04:55 UTC, FeepingCreature wrote:

>

a function in a module is "on the same level" as a method in the class.

If it is on the same level, then I would expect 'foo' below to lock the mutex and run the invariant check:

synchronized class C
{
    private int x;
    private int y = 1;

    invariant() { assert(y == x + 1); }
}

void foo(C c, int x)
{
    c.x = x;
    c.y = x + 1;
}

And on reflection, I think I agree that it should.

June 20, 2022
On Monday, 20 June 2022 at 09:01:09 UTC, surlymoor wrote:
> On Monday, 20 June 2022 at 08:25:34 UTC, forkit wrote:
>> On Sunday, 19 June 2022 at 22:45:44 UTC, forkit wrote:
>>>[...]
>>
>> I'm happy (more than happy actually) to conclude my input into this discusssion with this:
>>
>> [...]
>
> Then draft a DIP to get the ball rolling.
> But you won't.

It has more chance of happening in D3.. but even, it's only a slight chance.

A DIP is pointless. The problem is:

 - there's just not enough OO programmers in the D community to get sufficient support for the idea. That gets clearly demonstrated whenever the idea emerges (again .. and again).

 - most D programmers seems to be using procedural decomposition, not OO decomposition.

- Walter has voiced his opinion on this matter. I cannot see how a DIP would change his perspective.

- Who would implement it? Walter? I mean c'mon..

My guess is, that those insisting that a DIP be produced, are likely those that know such a DIP will never be accepted. Then they can put this idea to rest, forever - cause the DIP was rejected.

Lastly, I have available, really good alternatives to D, for OOP. So I think my attention is better spend elsewhere now.

If D3 ever arrives on the scene, I'll take a brief look to see if anything has changed. But I doubt it will.


June 20, 2022
On Monday, 20 June 2022 at 09:01:09 UTC, surlymoor wrote:
> On Monday, 20 June 2022 at 08:25:34 UTC, forkit wrote:
>> On Sunday, 19 June 2022 at 22:45:44 UTC, forkit wrote:
>>>[...]
>>
>> I'm happy (more than happy actually) to conclude my input into this discusssion with this:
>>
>> [...]
>
> Then draft a DIP to get the ball rolling.
> But you won't.

Why waste hours writing a DIP when there's a better chance of winning the lottery than to have this accepted as a DIP.

I think it's okay to express your dislikes and what you wished D could do better, without necessarily putting in the work yourself for the change; especially when it is something as divided as this.

I don't think it would pass, the same way that the default we have now wouldn't pass a DIP either.

It's just a too dividend topic and I don't think either side of the coin is inherently wrong, it just depends on your usage of D and what your background is, I think people coming from Java, C# etc. tends to favor this change, where the opposite is true for people coming from C, C++ etc.

I do however also think that enough is enough, clearly the dislike has been expressed enough and at some point you just gotta stop complaining.

But I also believe that "writing a DIP" isn't always an acceptable response, even if that's what's needed to make the change.

Before one writes a DIP you need

a) make sure there is sufficient support for the implementation
b) make sure the topic has a chance of passing

"class private" only passes a) but not b)
June 20, 2022
On 20/06/2022 9:30 PM, bauss wrote:
> It's just a too dividend topic and I don't think either side of the coin is inherently wrong, it just depends on your usage of D and what your background is, I think people coming from Java, C# etc. tends to favor this change, where the opposite is true for people coming from C, C++ etc.
> 
> I do however also think that enough is enough, clearly the dislike has been expressed enough and at some point you just gotta stop complaining.

Most people don't care about it as a feature.

There was very little dislike being expressed in this thread, mostly indifference.

It would pass if for no other reason than to stop this topic coming up in the future.

So yes, there is very much a point to do a DIP, especially when Mike has offered to give it preferential treatment!
June 20, 2022

On Monday, 20 June 2022 at 09:27:59 UTC, FeepingCreature wrote:

>

On Saturday, 18 June 2022 at 18:02:08 UTC, Max Samukha wrote:

>

On Saturday, 18 June 2022 at 08:04:55 UTC, FeepingCreature wrote:

>

a function in a module is "on the same level" as a method in the class.

If it is on the same level, then I would expect 'foo' below to lock the mutex and run the invariant check:

synchronized class C
{
    private int x;
    private int y = 1;

    invariant() { assert(y == x + 1); }
}

void foo(C c, int x)
{
    c.x = x;
    c.y = x + 1;
}

And on reflection, I think I agree that it should.

Me, too. This is an aspect I hadn't considered before. It's given me an idea.

June 20, 2022
On Monday, 20 June 2022 at 09:30:18 UTC, bauss wrote:
> On Monday, 20 June 2022 at 09:01:09 UTC, surlymoor wrote:
>> On Monday, 20 June 2022 at 08:25:34 UTC, forkit wrote:
>>> On Sunday, 19 June 2022 at 22:45:44 UTC, forkit wrote:
>>>>[...]
>>>
>>> I'm happy (more than happy actually) to conclude my input into this discusssion with this:
>>>
>>> [...]
>>
>> Then draft a DIP to get the ball rolling.
>> But you won't.
>
> Why waste hours writing a DIP when there's a better chance of winning the lottery than to have this accepted as a DIP.
>
> I think it's okay to express your dislikes and what you wished D could do better, without necessarily putting in the work yourself for the change; especially when it is something as divided as this.

I'd be hypocrite to disagree, but the topic at hand, as you've noted, has been exhausted. And yet, the main complainant seems to still have plenty of energy. Thus, why not put that towards something more substantive instead continually serving stale bread?
June 20, 2022
On 6/19/2022 2:40 AM, Max Samukha wrote:
> Rust in general is a great counterevidence to Walter's belief that a programming language should care about human interface.

Rust has the best language marketers I've ever seen.
June 20, 2022
On Monday, 20 June 2022 at 09:43:42 UTC, rikki cattermole wrote:
>
> On 20/06/2022 9:30 PM, bauss wrote:
>> It's just a too dividend topic and I don't think either side of the coin is inherently wrong, it just depends on your usage of D and what your background is, I think people coming from Java, C# etc. tends to favor this change, where the opposite is true for people coming from C, C++ etc.
>> 
>> I do however also think that enough is enough, clearly the dislike has been expressed enough and at some point you just gotta stop complaining.
>
> Most people don't care about it as a feature.
>
> There was very little dislike being expressed in this thread, mostly indifference.
>
> It would pass if for no other reason than to stop this topic coming up in the future.
>
> So yes, there is very much a point to do a DIP, especially when Mike has offered to give it preferential treatment!

no. It should only ever pass, on the basis, that it enhances software engineering.

the language and compiler is essentially just an app, and should serve the needs of those using it, not those designing it.

to the extent it does just that, for 'most' D users, fine.

it doesn't for me though.

Private members have ALWAYS been a vital component in my software engineering processes, and it will remain so.

what I've always found puzzling, is that so many in the D community are against this. I don't mean in favour of the status quo (private to the module), but being **so against** just the 'option' - which they would always retain the right to use, or not, according to what they think enhances (or doesn't) their software engineering process.

There are numerous explanations I can come up with for this. Any or all could well be true.

Also, the discussion has mostly not been about complaining, as someone suggested, but having to respond to the D community's complete and utter dislike of this idea - that's where all the effort goes really.

I think D3 should maybe get rid of the class type completely, and stop trying to pretend it supports OOP. Then there will no longer ever be any confusion, discussion, complaining...... ever again.





June 20, 2022
On Monday, 20 June 2022 at 23:36:43 UTC, forkit wrote:
>

look, even typescript have shown this courtesy to OO programmers:

https://www.typescriptlang.org/docs/handbook/classes.html