February 14, 2023
On Tuesday, 14 February 2023 at 08:15:37 UTC, Kagamin wrote:
> My point is you know you're just picky.

Well.. it seems to me, that your 'point' is to just have a go at me.

In any case, there is nothing 'picky' about wanting to be able to explicately 'declare' a member of my class type as being private. That to me, is what a programmer should expect to be able to do in a language that says it supports OOP.

Further nonsense towards me will be ignored ;-)
February 14, 2023
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide wrote:
> On Tuesday, 14 February 2023 at 08:15:37 UTC, Kagamin wrote:
>> My point is you know you're just picky.
>
> Well.. it seems to me, that your 'point' is to just have a go at me.
>
> In any case, there is nothing 'picky' about wanting to be able to explicately 'declare' a member of my class type as being private. That to me, is what a programmer should expect to be able to do in a language that says it supports OOP.
>
> Further nonsense towards me will be ignored ;-)

fight fight fight fight

jk
February 14, 2023
On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide wrote:

> In any case, there is nothing 'picky' about wanting to be able to explicately 'declare' a member of my class type as being private. That to me, is what a programmer should expect to be able to do in a language that says it supports OOP.

What you are saying is that you want an implementation of a particular language that calls itself an OOP language. [There is a lot of controversy about the definition of OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not think the explicit ability to declare a member of a class private in a particular way has anything to do with it. You are certainly entitled to your opinion, but it doesn't help to say D is not an OOP language because you don't like some of the design decisions.
February 14, 2023
On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote:
> On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide wrote:
>
>> In any case, there is nothing 'picky' about wanting to be able to explicately 'declare' a member of my class type as being private. That to me, is what a programmer should expect to be able to do in a language that says it supports OOP.
>
> What you are saying is that you want an implementation of a particular language that calls itself an OOP language. [There is a lot of controversy about the definition of OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not think the explicit ability to declare a member of a class private in a particular way has anything to do with it. You are certainly entitled to your opinion, but it doesn't help to say D is not an OOP language because you don't like some of the design decisions.

It's true that not everybody understands what OOP is.

But I think everyone would agree, that data hiding is at the core.

First, I'm not advocating for OOP, or against it.

It's just a tool that's suitable in some scenarios, and not it others.

I'm also not a OOP purist.

Now with that out of the way....

D claims to support OOP. Put that to the test. Because there is a difference between programming with modules ('Decide which modules you want and partition the program so that data is hidden in modules.') and programming with 'user-defined types' ('Decide which types you want and provide a full set of operations for each type').

Data hiding is at the core of using modules.

It's also at the core of using types.

I refer interested people to:

"Most, but not all, modules are better expressed as user defined types." -

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

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


February 15, 2023
On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote:
> On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide wrote:
>
>> In any case, there is nothing 'picky' about wanting to be able to explicately 'declare' a member of my class type as being private. That to me, is what a programmer should expect to be able to do in a language that says it supports OOP.
>
> What you are saying is that you want an implementation of a particular language that calls itself an OOP language. [There is a lot of controversy about the definition of OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not think the explicit ability to declare a member of a class private in a particular way has anything to do with it. You are certainly entitled to your opinion, but it doesn't help to say D is not an OOP language because you don't like some of the design decisions.

D is still an OOP language, as long as it has classes, inheritance, and polymorphism, though it's certainly not a good one if any class can acccess private members from the module, that's just horrid.
February 15, 2023
On Wednesday, 15 February 2023 at 01:15:09 UTC, thebluepandabear wrote:
> On Tuesday, 14 February 2023 at 15:34:17 UTC, bachmeier wrote:
>> On Tuesday, 14 February 2023 at 10:16:47 UTC, ProtectAndHide wrote:
>>
>>> In any case, there is nothing 'picky' about wanting to be able to explicately 'declare' a member of my class type as being private. That to me, is what a programmer should expect to be able to do in a language that says it supports OOP.
>>
>> What you are saying is that you want an implementation of a particular language that calls itself an OOP language. [There is a lot of controversy about the definition of OOP](https://wiki.c2.com/?NobodyAgreesOnWhatOoIs). I do not think the explicit ability to declare a member of a class private in a particular way has anything to do with it. You are certainly entitled to your opinion, but it doesn't help to say D is not an OOP language because you don't like some of the design decisions.
>
> D is still an OOP language, as long as it has classes, inheritance, and polymorphism, though it's certainly not a good one if any class can acccess private members from the module, that's just horrid.

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.
February 15, 2023
On Wednesday, 15 February 2023 at 01:16:00 UTC, thebluepandabear wrote:

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

D does not lack encapsulation, it's just that the unit of encapsulation is the module. Everything private in a module is encapsulated from the perspective of the public API.

If you really want to prevent anything inside a module from accessing the private parts of a class, you can put the class in its own module.

Must we continue beating this horse?
February 15, 2023

On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker wrote:

>

On Wednesday, 15 February 2023 at 01:16:00 UTC, thebluepandabear wrote:

>

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.

D does not lack encapsulation, it's just that the unit of encapsulation is the module. Everything private in a module is encapsulated from the perspective of the public API.

If you really want to prevent anything inside a module from accessing the private parts of a class, you can put the class in its own module.

Must we continue beating this horse?

Time to move on to OCaml programmers telling us D doesn't have floating point arithmetic because there's no +. operator.

February 15, 2023
>

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.

February 15, 2023
On Wednesday, 15 February 2023 at 02:14:30 UTC, Mike Parker wrote:
> On Wednesday, 15 February 2023 at 01:16:00 UTC, thebluepandabear wrote:
>
>>
>> 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.
>
> D does not lack encapsulation, it's just that the unit of encapsulation is the module. Everything private in a module is encapsulated from the perspective of the public API.
>
> If you really want to prevent anything inside a module from accessing the private parts of a class, you can put the class in its own module.
>
> Must we continue beating this horse?

Why is the unit of encapsulation the module though? Makes no sense.