On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:

> Wrong. I'm arguing  things:

Geez. "I'm arguing 2 things:"

On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:
> On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide wrote:
>
>>
>> What Mike is arguing, is that I don't need a 'data hiding' mechanism for a user-defined type, because that is already provided to me by the 'data hiding' mechanism of the module.
>>
>> That is his argument.
>>
>> My argument is that I want 'data hiding' mechanism at the user-defined type level as well.
>>
>> Again, his argument is that i don't need it.. because...
>>
>>
>
> Wrong. I'm arguing  things:
>
> 1. D has encapsulation (you say it doesn't).
> 2. We don't need a new protection attribute or a redefinition of private because D already provides the mechanism to give you what you want.

Honestly. How hard is it for you to accept? It's so simple I could explain it to first year programmer!

It's really straight forward, obvious, correct, and can be demonstrated like this:

// foo type has no ability (at the type level)
// to hide anything from other code in the module.
// this is fact. I'm not making it up!
// There is nothing to argue against here. It's just fact.

module test;
@safe:

import std;

class foo { private int x = 10; } // C++, C#, Swift, Javascript...programmers - beware!

void main()
{
    foo f = new foo;

    f.x = 20; // D provides no way to prevent this from occuring as there is no mechanism at the type level to do this. Instead you have to put foo in a module by itself, so no other code can access x. So EVERY user-defined type that wants data hiding from users of that type (including other code in the module using that type), must be in its own module.


    writeln(f.x);
}


I understand your argument completely. Just put foo in its own module. I get it.

What you don't get, is that I want such design decisions to be in my hands, and not yours.

That is, I want a mechanism at the type level as well.

You don't want me to have that. Well fine.

But at stop mispresenting what I'm saying. What I've stated above, is what I'm saying.. no more.. no less.

On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:
> On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide wrote:
>
>>
>> What Mike is arguing, is that I don't need a 'data hiding' mechanism for a user-defined type, because that is already provided to me by the 'data hiding' mechanism of the module.
>>
>> That is his argument.
>>
>> My argument is that I want 'data hiding' mechanism at the user-defined type level as well.
>>
>> Again, his argument is that i don't need it.. because...
>>
>>
>
> Wrong. I'm arguing  things:
>
> 1. D has encapsulation (you say it doesn't).

My code in my previous post should make it clear what I'm saying. Stop misrepresenting my argument.

> 2. We don't need a new protection attribute or a redefinition of private because D already provides the mechanism to give you what you want.

First, who is 'we'? Likely the programmers that do need it, have decided to go elsewhere (where they can get it, and have likely had it, for decades - not in some obscure language, but in the most major languages being used.).

Second, you don't provide what I want. You can keep saying that you do, but that doesn't change it.

C++, C#, Swift, hell even Javascript.. they provide what I want. D does not. So don't say it does, until it does...and that day will come ;-)

On Thursday, 16 February 2023 at 02:56:28 UTC, ProtectAndHide wrote:
>

What a joke. Even Javascript can do this (and the compile will enforce it too).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Private_class_fields

>
> But at stop mispresenting what I'm saying. What I've stated above, is what I'm saying.. no more.. no less.

Well said.

Its not that hard to understand, folks.

On Thursday, 16 February 2023 at 02:27:23 UTC, Mike Parker wrote:
> On Thursday, 16 February 2023 at 02:26:44 UTC, Mike Parker wrote:
>
>> Wrong. I'm arguing  things:
>
> Geez. "I'm arguing 2 things:"

Springboarding off this post:

This thread is vastly dominated by some people who care very much about this issue. Comparatively, for instance, I care very little because I think D already does it right.

But then the thread will look unbalanced. This is a fundamental design flaw in forum software.

So let me just say: I think D does it right. D does not have class encapsulation; it has module encapsulation. This is by design, and the design is good.

> So let me just say: I think D does it right. D does not have class encapsulation; it has module encapsulation. This is by design, and the design is good.

The design is terrible...

On Thu, Feb 16, 2023 at 08:51:39AM +0000, FeepingCreature via Digitalmars-d-learn wrote: [...]
> Springboarding off this post:
> 
> This thread is vastly dominated by some people who care very much about this issue. Comparatively, for instance, I care very little because I think D already does it right.
> 
> But then the thread will look unbalanced. This is a fundamental design flaw in forum software.
> 
> So let me just say: I think D does it right. D does not have class encapsulation; it has module encapsulation. This is by design, and the design is good.

+1, this issue is wayyy overblown by a vocal minority. D's design diverges from other languages, but that in itself does not make it a bad design.  In the context of D it actually makes sense. Saying that D's design is bad because language X does it differently is logically fallacious (X is good, Y is not X, therefore Y is bad).


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter

On Thursday, 16 February 2023 at 13:39:13 UTC, H. S. Teoh wrote:
> On Thu, Feb 16, 2023 at 08:51:39AM +0000, FeepingCreature via Digitalmars-d-learn wrote: [...]
>> Springboarding off this post:
>> 
>> This thread is vastly dominated by some people who care very much about this issue. Comparatively, for instance, I care very little because I think D already does it right.
>> 
>> But then the thread will look unbalanced. This is a fundamental design flaw in forum software.
>> 
>> So let me just say: I think D does it right. D does not have class encapsulation; it has module encapsulation. This is by design, and the design is good.
>
> +1, this issue is wayyy overblown by a vocal minority. D's design diverges from other languages, but that in itself does not make it a bad design.  In the context of D it actually makes sense. Saying that D's design is bad because language X does it differently is logically fallacious (X is good, Y is not X, therefore Y is bad).
>
>
> T

It's really the vocal majority that makes this issue overblown.

One person saying they don't like something...dozens deciding to weigh in and say how wrong he is. So whose doing the overblowing?

The 'fact' of the matter is, that the vast majority of programmers in the most major languages have the capacity to explicately declare hidden data associated with their user-defined type (class, struct..whatever).

Both the module type, and the class type need this capability.

One without the other leads to the kind of errors I made when I first started writing classes in D (which of course I now longer use D for).

So for the D's 'majority' to flood this thread saying 'no we're right and you're wrong' and all the other major languages in the world are wrong, as are their designers, and all the programmers using them are blind, and don't really need that capability... I mean really? Are we meant to take that seriously?

D was clearly created by procedural programmers for procedural programmers.

And again, a language that deliberately forces an important design decision onto programmers (one-user-defined-type per module just to protect its hidden data), is wrong. D people saying its fine, are wrong. It's just wrong.

If you think its not wrong, you are wrong.

A user-defined type where the programmer cannot explicately declare protected hidden data, is wrong.

If you think its not wrong, you are wrong.