June 19, 2022

On Sunday, 19 June 2022 at 06:22:57 UTC, forkit wrote:

>

"Software entities (classes, modules, functions, etc.) Should be open for extension, but closed for modification."

This is the problem of D. when it is very obvious ,then they must oppose it.
Finally, they say that they are experts which should break the (rules or)consistency!
We are the first!
Therefore, D's community is small .

June 19, 2022
On Sunday, 19 June 2022 at 06:46:17 UTC, Paulo Pinto wrote:
> 
> ..
> As I already mentioned on the other thread, CS literature is full of various understandings of what is OOP all about.

so is 20+ years of doing it ;-)

June 19, 2022
On Sunday, 19 June 2022 at 07:01:38 UTC, forkit wrote:
> On Sunday, 19 June 2022 at 06:46:17 UTC, Paulo Pinto wrote:
>> 
>> ..
>> As I already mentioned on the other thread, CS literature is full of various understandings of what is OOP all about.
>
> so is 20+ years of doing it ;-)

also, by view of OOP, is that any principles you apply to it, confirm with principles in the real world.

e.g. you cannot turn a cat into a mouse.

although having said that, they're both made of molecules, that are made of atoms.

so you can turn atoms, into molecules, and molecules into a cat, or a mouse.

but as long as the cat is a cat, it's a cat, not a mouse.
June 19, 2022
On Saturday, 18 June 2022 at 21:17:52 UTC, Walter Bright wrote:

> Not even Andrei agreed with me. Not a single person that I recall.
>
> Anytime one interfaces with humans, inconsistency turns out to be desirable.
>
> Here's another inconsistency:
>
>   void func()
>   {
>       int a;
>       {
>          int a;  // error
>       }
>    }

It seems we are talking about different kinds of inconsistency. I am talking about logical inconsistencies (contradictions) in the rules, e.g. 'invariant/synchronized' imply class-level encapsulation while the encapsulation is enforced with 'private', which is module-level. The special shadowing rules do not seem to introduce any logical inconsistencies. Also, there is already one human in this thread who is claiming they are annoying.))

June 19, 2022

On Sunday, 19 June 2022 at 07:07:07 UTC, Max Samukha wrote:

>

The special shadowing rules do not seem to introduce any logical inconsistencies.

It is inconsistent with scoping semantics: classes within classes, structs within structs, and you are allowed to shadow globals. Yet shadowing when subclassing is allowed?

It is just a personal style guideline that is forced on everybody for no particular reason, it is not a common mistake to make if you know what you are doing.

June 19, 2022

On Sunday, 19 June 2022 at 07:41:37 UTC, Ola Fosheim Grøstad wrote:

>

On Sunday, 19 June 2022 at 07:07:07 UTC, Max Samukha wrote:

>

The special shadowing rules do not seem to introduce any logical inconsistencies.

It is inconsistent with scoping semantics: classes within classes, structs within structs, and you are allowed to shadow globals. Yet shadowing when subclassing is allowed?

It is just a personal style guideline that is forced on everybody for no particular reason, it is not a common mistake to make if you know what you are doing.

This is also legal, if you care about shadowing then this is a much more likely problem:


class A {
    int x;
    void increment(){
        // lots of code
        int x;
        // lots of code
        x++;
    }
}

So that scoping restriction is completely arbitrary.

I believe Rust allows rebinding the name within the same scope, which might be unreasonable, but there is one advantage: you get to use a consistent naming scheme which makes code easier to read.

June 19, 2022
On Saturday, 18 June 2022 at 05:50:56 UTC, Walter Bright wrote:
>
> Consistency is a worthy goal, but as I explained in my recent Code Europe presentation, too much consistency leads to undesirable results, too.
>
> For example:
>
>     for (int i = 0; i; ++i);
>     {
>         ...
>     }
>
> D adds grammatical inconsistency to reject that.
>
> And then there's that famously inconsistent symbol table lookup that D does that everyone but me insisted is intuitive :-)

I'm not sure consistency with C, is necessarily a worthy goal.

Of course you've demonstrated that in your for loop example (i.e. a good reason for D to not be consistent here).

I can easily understand your reason for wanting to be inconsistent here. I've made this mistake numerouse times myself, as I'm sure many others have.

What I cannot understand, is your refusal to allow a class to declare something private to the class. I'm not aware of programmers making mistakes because they declared something in a class to be private. If the made a mistake, it's a design mistake, not a mistake of being able to declare something private to a class.

What is the rationale for this inconsistency in D?

The only explanation I've ever seen from you, on this issue, is that "in D, the module is the unit of encapsualtion". But that is not a rationale for being inconsistent here.

What is the rationale?

June 19, 2022
On Sunday, 19 June 2022 at 07:06:21 UTC, forkit wrote:
> On Sunday, 19 June 2022 at 07:01:38 UTC, forkit wrote:
>> On Sunday, 19 June 2022 at 06:46:17 UTC, Paulo Pinto wrote:
>>> 
>>> ..
>>> As I already mentioned on the other thread, CS literature is full of various understandings of what is OOP all about.
>>
>> so is 20+ years of doing it ;-)
>
> also, by view of OOP, is that any principles you apply to it, confirm with principles in the real world.
>
> e.g. you cannot turn a cat into a mouse.
>
> although having said that, they're both made of molecules, that are made of atoms.
>
> so you can turn atoms, into molecules, and molecules into a cat, or a mouse.
>
> but as long as the cat is a cat, it's a cat, not a mouse.

Last time I checked, Common Lisp, JavaScript and ML derived languages like Objective Caml are still real world, used at places like Google and Facebook.

But I digress...
June 19, 2022
On Saturday, 18 June 2022 at 21:17:52 UTC, Walter Bright wrote:
> On 6/18/2022 2:42 AM, Max Samukha wrote:
>> You might have based your decisions on the feedback by the vociferous few while there is the silent majority whose opinion is unknown. I've been familiar with D since around 2006 and never voiced my opinion about the module-level private until now.
>
> Not even Andrei agreed with me. Not a single person that I recall.
>
> ....

Can I interpret that as meaning, Andrei did not agree with the idea of the D module making class variables and members global to the module?

Is that what you meant?

Is this still his opinion?

June 19, 2022
On Sunday, 19 June 2022 at 08:13:54 UTC, Paulo Pinto wrote:
> On Sunday, 19 June 2022 at 07:06:21 UTC, forkit wrote:
>> On Sunday, 19 June 2022 at 07:01:38 UTC, forkit wrote:
>>> On Sunday, 19 June 2022 at 06:46:17 UTC, Paulo Pinto wrote:
>>>> 
>>>> ..
>>>> As I already mentioned on the other thread, CS literature is full of various understandings of what is OOP all about.
>>>
>>> so is 20+ years of doing it ;-)
>>
>> also, by view of OOP, is that any principles you apply to it, confirm with principles in the real world.
>>
>> e.g. you cannot turn a cat into a mouse.
>>
>> although having said that, they're both made of molecules, that are made of atoms.
>>
>> so you can turn atoms, into molecules, and molecules into a cat, or a mouse.
>>
>> but as long as the cat is a cat, it's a cat, not a mouse.
>
> Last time I checked, Common Lisp, JavaScript and ML derived languages like Objective Caml are still real world, used at places like Google and Facebook.
>
> But I digress...

well, in the real world, a cat 'could' turn into mouse.

but only once all the molecules have dissipated (from death).

but whether those atoms will from new molecules, that create a mouse, nobody knows.

therefore, I cannot see why CLOS allows you to turn a cat into a mouse.

I can only surmise, that CLOS programmers like playing god ;-)

"playing god" != "OOP"

.. but i digress too ...