On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide wrote:
>

My agrument is this:

Objects are data abstractions with an interface of named operations and a hidden local state. Does anyone disagree with this?

D does not have a language mechanism, but rather a design mechanism that supports the above.
By that I mean, you cannot use a language 'declaration' mechanism to enforce the above, but rather have to revert to a design mechanism - putting the class that represents that object into a module by itself. Does anyone disagrre with this?

Forcing programmers to use a design mechanism rather than a language mechanism to achieve the above abstraction is wrong. This seems to be the source of the disagreement, correct?

So some think its fine to force this onto programmers? That is essentially your argument... right?

On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide wrote:

> Forcing programmers to use a design mechanism rather than a language mechanism to achieve the above abstraction is wrong. This seems to be the source of the disagreement, correct?

There's no disagreement. It's you posting the same false claim again and again (presumably because you're hoping it will come up when someone does a search for it, or some similar reason) and others explaining why you're wrong.

If you don't want to use the language, don't use it. You have your subjective preferences. You are unable to muster a good argument in favor of it. There's no reason to (yet again) post the same thing over and over.

On Thursday, 16 February 2023 at 21:56:03 UTC, bachmeier wrote:
> On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide wrote:
>
>> Forcing programmers to use a design mechanism rather than a language mechanism to achieve the above abstraction is wrong. This seems to be the source of the disagreement, correct?
>
> There's no disagreement. It's you posting the same false claim again and again (presumably because you're hoping it will come up when someone does a search for it, or some similar reason) and others explaining why you're wrong.
>
> If you don't want to use the language, don't use it. You have your subjective preferences. You are unable to muster a good argument in favor of it. There's no reason to (yet again) post the same thing over and over.

It's your claim that is false.

What I outlined is correct. I've even shown code that clearly demonatrates it.

I don't know how you can call those claims false. They are fact. And any D programmers know what I've said is correct.

The disagreement, is whether D should do something about it. Not that what I've demonstrated is incorrect.

Also, I don't keep posting just cause I like to doing it. I'm responding to people like you who continually make accusations against me which are not correct.

Try focusing on the source of the disagreement, and not on personal issues.

Then we will not have this constant to and fro. Instead, we will end up disagreeing on some language design issue, and that will be that.

Stop making it personal!

On Thursday, 16 February 2023 at 21:56:03 UTC, bachmeier wrote:
> On Thursday, 16 February 2023 at 21:23:53 UTC, ProtectAndHide wrote:
>
>> Forcing programmers to use a design mechanism rather than a language mechanism to achieve the above abstraction is wrong. This seems to be the source of the disagreement, correct?
>
> There's no disagreement. It's you posting the same false claim again and again (presumably because you're hoping it will come up when someone does a search for it, or some similar reason) and others explaining why you're wrong.
>
> If you don't want to use the language, don't use it. You have your subjective preferences. You are unable to muster a good argument in favor of it. There's no reason to (yet again) post the same thing over and over.


also, I noticed that you intentionally? did not respond to the facts that I outlined:

ie.

Objects are data abstractions with an interface of named operations and a hidden local state. Does anyone disagree with this?

D does not have a language mechanism, but rather a design mechanism that supports the above.
By that I mean, you cannot use a language 'declaration' mechanism to enforce the above, but rather have to revert to a design mechanism - putting the class that represents that object into a module by itself. Does anyone disagrre with this?

Forcing programmers to use a design mechanism rather than a language mechanism to achieve the above abstraction is wrong. This seems to be the source of the disagreement, correct?

So some think its fine to force this onto programmers? That is essentially your argument... right?

This is about the language. It's not personal. Don't make it personal!

On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide wrote:
> Both the module type, and the class type need this capability.

No, they are not.
Look at Go.

Data hiding is overrated.
Furthermore, OOP is overrated :-)

https://betterprogramming.pub/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7

On Friday, 17 February 2023 at 04:43:11 UTC, RTM wrote:
> On Thursday, 16 February 2023 at 20:56:00 UTC, ProtectAndHide wrote:
>> Both the module type, and the class type need this capability.
>
> No, they are not.
> Look at Go.

Go does not have classes.