On Wednesday, 15 February 2023 at 10:17:30 UTC, Mike Parker wrote:
>
> I referenced that in my post. The exact same problem exists *inside* the class when your class file is very long. You can easily manipulate the private member even when it's only supposed to be accessed by a specific function.

You're missing the point, completely.

We're discussing the issue of type safety.

Your talking about typing mistakes.

> .. in D: the private implementation is in the source file. The fact that the source file represents a module rather than a single class is irrelevant.

Again, this is about type safety, supported by the compiler.

Read that article by Stroustup that I cited, so you can obtain a clearer understanding what it is 'he' is saying, because what I am saying.

In essence, he discusses how inferior a type created  through  a module mechanism is, compared to a user-defined type (and that user-defined types were provided by languages for that very reason). The key being, that user-defined types provide their own mechanism for data hiding (the representation is private). D's module system supports this, but it does not 'enable' it. i.e. it supports it by forcing the programmer to put that type into its own module.

> We keep repeating the same arguments over and over and over again on this......

That's because the key idea being presented here, is not being taken on board.

A user-defined type is a type that has a mechanism to keep it representation private.

D does not support this. It only enables it.

You (and others) may well argue that D should not enable this (directly), it should only support it (indirectly), and thus allow the language to force an important design decision onto programmers.

As a programmer, I don't think that is acceptable.

On Wednesday, 15 February 2023 at 19:44:50 UTC, ProtectAndHide wrote:
>

"The basic support for programming with data abstraction consists of facilities for defining a set of operations (functions and operators) for a type and for restricting the access to objects of the type to that set of operations."

D does not enable this. It only supports it, because the programmer has to revert to 'data hiding techniques' at the module level, instead of at the type level.

D should enable programmers to express and utilise 'proper' types, just as C++, C#, Swift can... hell, even Javascript enables programmers to do this.

What is 'Object-Oriented Programming'? (1991 revised version) Bjarne Stroustrup

https://www.stroustrup.com/whatis.pdf

On Wednesday, 15 February 2023 at 20:01:12 UTC, bachmeier wrote:
> On Wednesday, 15 February 2023 at 19:44:50 UTC, ProtectAndHide wrote:
>
>> A user-defined type is a type that has a mechanism to keep it representation private.
>>
>> D does not support this. It only enables it.
>>
>> You (and others) may well argue that D should not enable this (directly), it should only support it (indirectly), and thus allow the language to force an important design decision onto programmers.
>>
>> As a programmer, I don't think that is acceptable.
>
> The response was to your claim that "I think what you could say is that D lacks _encapsulation_ which is also an OOP concept. So D is partially OOP but not fully OOP due to there being no encapsulation in the language."
>
> Mike demonstrated clearly that your claim is false.


My claims are factually correct.

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...

And my argument is, that I want it...

And his arguement is, that I don't need it..

And...

And.....

And.......

On Wednesday, 15 February 2023 at 20:10:31 UTC, ProtectAndHide wrote:
>
>...

this is not to be personal, just to make an analogy about the point being made:

if Mike was a car salesperson, he'd be arguing that I don't need an automatic transmission. I can already do it manually. Why should we complicate our design by making an automatic tranmission if you can alreay change gears anyway.

Well..do you think I'd end up buying my new car from him?

On Wednesday, 15 February 2023 at 20:34:13 UTC, thebluepandabear wrote:
> On Wednesday, 15 February 2023 at 20:06:18 UTC, bachmeier wrote:
>> On Wednesday, 15 February 2023 at 07:13:41 UTC, thebluepandabear wrote:
>>>> Time to move on to OCaml programmers telling us D doesn't have floating point arithmetic because there's no `+.` operator.
>>>
>>> that's not the same thing though, you've created a great false equivalence! Congrats.
>>
>> Only if you don't understand D's encapsulation. You're going on at length (apparently under multiple names in this thread) because you don't like D's implementation of encapsulation. That's no different from complaining that the `+` operator should be `+.`, and until D makes the change, it doesn't support floating point addition.
>>
>> There are reasonable arguments for changing and not changing D's implementation of encapsulation. Your claim that D doesn't support encapsulation is false.
>
> 'under multiple names'... You can clearly see I have the same name, simply different profile pictures.


You should know by now, that anyone that supports the idea of D providing an explicit mechanism to support data hiding for a user-defined type, are all the **same** person.

Nobody else in the world supports such an idea.

It's all just one person... apparently ;-)

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.