On Saturday, 3 November 2018 at 00:44:15 UTC, Laeeth Isharc wrote:
> When one encounters a new idea that's unfamiliar sometimes it's easy to think that because it's unfamiliar it must be unsound.  That can be a mistake.  It might be better to suspend judgement for a while and keep an open mind.

I believe that responses like this, are really just designed to further obfuscate the point I'm trying to make, so that it cannot progress any further.

Now, speaking of keeping an open mind....let's get back to my point.. can we?

(q1) Why is it, that people who use D, object *so much* to the idea of allowing (at the choice of the programmer) for a type to have it's own private state *within* a module (so that its private state is respected by other code also within that module)?

Or you ask it another way:

(q2)Why must a type within a module *always* have its private state exposed to other code within the module? (the key word here, being 'always').

Both questions seem very reasonable to ask, in my opinion, not matter what background you have.

(q3) Should a language intentionally set out to prevent a programmer from making that choice?

please stop obfuscating, and try to answer the questions.

On Sat, 03 Nov 2018 04:50:52 +0000, unprotected-entity wrote:
> (q1) Why is it, that people who use D, object *so much* to the idea of
> allowing (at the choice of the programmer) for a type to have it's own
> private state *within* a module (so that its private state is respected
> by other code also within that module)?

We object because the people complaining can't point at a use case that seems reasonable. If you provided real-world examples, we'd consider them.

We are further disinclined to engage with you as a collaborator because you're insulting us and ignoring a lot of our responses to you.

> Or you ask it another way:
> 
> (q2)Why must a type within a module *always* have its private state
> exposed to other code within the module? (the key word here, being
> 'always').

Because that is both simple and flexible. Swift forsakes simplicity in favor of high granularity, and it's exhausting just reading its protection modifier list.

> (q3) Should a language intentionally set out to prevent a programmer
> from making that choice?

You're mischaracterizing the situation to make your preferred feature look like the default. That's the opposite of how language design works. Nothing is there by default. You add things as necessary to get a language that's good enough.

On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh wrote:
> On Sat, 03 Nov 2018 04:50:52 +0000, unprotected-entity wrote:
>> (q1) Why is it, that people who use D, object *so much* to the idea of
>> allowing (at the choice of the programmer) for a type to have it's own
>> private state *within* a module (so that its private state is respected
>> by other code also within that module)?
>
> We object because the people complaining can't point at a use case that seems reasonable. If you provided real-world examples, we'd consider them.
>
> We are further disinclined to engage with you as a collaborator because you're insulting us and ignoring a lot of our responses to you.

This reasoning is meaningless: one must not prove the obvious.
During the writing of a complex module, it happened to me many times to desire what unprotected-entity asks.

And if the validity of a person's reasoning is a function of his way of expressing them, well ... do not pose to software engineers at least


>
>> Or you ask it another way:
>> 
>> (q2)Why must a type within a module *always* have its private state
>> exposed to other code within the module? (the key word here, being
>> 'always').
>
> Because that is both simple and flexible. Swift forsakes simplicity in favor of high granularity, and it's exhausting just reading its protection modifier list.
>
>> (q3) Should a language intentionally set out to prevent a programmer
>> from making that choice?
>
> You're mischaracterizing the situation to make your preferred feature look like the default. That's the opposite of how language design works. Nothing is there by default. You add things as necessary to get a language that's good enough.

What he asks is reasonable and useful, and help in a myriad of cases. I can not even see a disadvantage in the introduction of a true private attribute.

What you ask is reasonable and useful, and help in a myriad of cases. I can not even see a disadvantage in the introduction of a true private attribute.

But already, it seems that nobody still really understands how to use the DIP1000 in the practicality of its code, "const-immutable" is a failure, five hundred pages of reasoning about "shared", entire sections of language abandoned halfway .... a poor man is asked to bring evidence that the water is wet .... geezzzz

On Sat, 03 Nov 2018 11:24:06 +0000, FooledDonor wrote:
> And if the validity of a person's reasoning is a function of his way of expressing them, well ... do not pose to software engineers at least

If you want other people to do work for you, you need to convince them to do it. This is an open source project, so the appropriate way of doing this is with good reasoning and examples, not by insulting people.

This is true even if the feature seems obviously good and necessary to one or two people, if those people don't have abnormally large influence over the project.

On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh wrote:
> On Sat, 03 Nov 2018 04:50:52 +0000, unprotected-entity wrote:
>> (q1) Why is it, that people who use D, object *so much* to the idea of
>> allowing (at the choice of the programmer) for a type to have it's own
>> private state *within* a module (so that its private state is respected
>> by other code also within that module)?
>
> We object because the people complaining can't point at a use case that seems reasonable. If you provided real-world examples, we'd consider them.
>
> We are further disinclined to engage with you as a collaborator because you're insulting us and ignoring a lot of our responses to you.
>
>> Or you ask it another way:
>> 
>> (q2)Why must a type within a module *always* have its private state
>> exposed to other code within the module? (the key word here, being
>> 'always').
>
> Because that is both simple and flexible. Swift forsakes simplicity in favor of high granularity, and it's exhausting just reading its protection modifier list.
>
>> (q3) Should a language intentionally set out to prevent a programmer
>> from making that choice?
>
> You're mischaracterizing the situation to make your preferred feature look like the default. That's the opposite of how language design works. Nothing is there by default. You add things as necessary to get a language that's good enough.

la..de.da..de.dah...

really just sounds like more obfuscatation to me...

As I said, I don't think the 'please no, don't do it, it'll just make our syntax too complex' position can be taken seriously. And in any case, and how many time do I have to tell you this (turning your phrase to me, back on you), that this is NOT a request for change. This is just a discussion about what benefit it might provide, if the programmer had the choice to have declare private state for a type, and have the compiler enforce that design choice, by preventing other code within the module to have direct access to that types private state.

Now..go and read that last paragraph again...

no more obfuscation...please.

On Saturday, 3 November 2018 at 06:57:50 UTC, Neia Neutuladh wrote:
>
> We object because the people complaining can't point at a use case that seems reasonable. If you provided real-world examples, we'd consider them.
>

------
module test;

struct S
{
    private uint a;

    void setA(uint n)
    {
        // damn implicit conversions! I just hate them!
        if(n != 4294967286)
            this.a = n;
        else
            assert(0);
    }
}

void func(ref S s)
{
    s.a = -10; // this might be on line 856 in your module.
               // there's a good chance, that when you get to write line 856,
               // that you've forgotten why you had written setA, on line 7.
               // i.e. to get around D's outrageous implicit conversions!

    //  Even worse, in D, you may never know you mistyped here,
    //  until things go wrong..
    //  maybe terribly wrong.
    //  That's why I made 'a' private, and declared an interface for using it.
}

// compile with: -unittest -main
unittest
{
    S s = S();
    func(s); // oh no...why did you do that! no error though.

    s.setA(-10); // gee.. if only I could declare 'a' to be: __private
                 // then would I know something is wrong.
}


----------

On Saturday, 3 November 2018 at 20:38:29 UTC, unprotected-entity wrote:

As has been pointed out several times before, this is a contrived example. Allow a simple transformation:

```
module test;

struct S
{
    private uint a;

    void setA(uint n)
    {
        // damn implicit conversions! I just hate them!
        if(n != 4294967286)
            this.a = n;
        else
            assert(0);
    }

    void func()
    {
        s.a = -10; // this might be on line 856 in your module.
                   // there's a good chance, that when you get to write line 856,
                   // that you've forgotten why you had written setA, on line 7.
                   // i.e. to get around D's outrageous implicit conversions!

    //  Even worse, in D, you may never know you mistyped here,
    //  until things go wrong..
    //  maybe terribly wrong.
    //  That's why I made 'a' private, and declared an interface for using it.
    }
}

// compile with: -unittest -main
unittest
{
    S s = S();
    s.func(); // oh no...why did you do that! no error though.

    s.setA(-10); // gee.. if only I could declare 'a' to be: __private then would I know something is wrong... [except it's useless in this case]
}
```

The only difference is that `func` became a member function. And now what? You can just as easily "forget" what's in your struct/class as in your whole module.

On 11/2/2018 5:44 PM, Laeeth Isharc wrote:
> When one encounters a new idea that's unfamiliar sometimes it's easy to think that because it's unfamiliar it must be unsound. That can be a mistake.  It might be better to suspend judgement for a while and keep an open mind.

So true. My ideas on how to write code have changed dramatically over the years, and continue to change.

On Saturday, 3 November 2018 at 16:21:36 UTC, Neia Neutuladh wrote:
> On Sat, 03 Nov 2018 11:24:06 +0000, FooledDonor wrote:
>> And if the validity of a person's reasoning is a function of his way of expressing them, well ... do not pose to software engineers at least
>
> If you want other people to do work for you, you need to convince them to do it. This is an open source project, so the appropriate way of doing this is with good reasoning and examples, not by insulting people.

The answer to your "if" is: NO, this is not the topic.

The argument is: does the induction of a true "private" attribute add value to the language or not? It is possible to discuss, in these forums, or everything must be truncated with "if you want to do it, and best wishes to convince then W & A"

> This is true even if the feature seems obviously good and necessary to one or two people, if those people don't have abnormally large influence over the project.

Nothing is "necessary" to a language outside "turing completeness".

Can we argue about the problems arising from the potential introduction of this feature?

On Sun, 04 Nov 2018 11:36:39 +0000, FooledDonor wrote:
> Can we argue about the problems arising from the potential introduction of this feature?

There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain.

So instead, we need to aggressively filter out potential added features to ensure that what they add is sufficiently important to justify later maintenance costs and the effort of learning things.

The justification for this feature rests on real-world examples of bugs that have been caused by its lack.