On Monday, 21 May 2018 at 14:46:40 UTC, Sjoerd Nijboer wrote:
>
> This hypotetical unittest is testing a hypotetical class in a hypotetical module with hypotetical properties.
> Why is it outside the class? I don't know, maybe it needs access to two classes which are defined in thesame module. But also out of personal preference, I don't like random unittest declarations inside my class. Regardless, I think it's important for unittests to be able to do this.
>

Fair enough. That is a reasonable position, I guess.

OK. So let's say, that the class-oriented programmer is now required to use one-class-per-module in D (in order to ensure the encaspulated private parts of the object are not penetrated by its neigbours in the module) - i.e the solution that most here seem to be suggesting.

Now, lets say that programmers wants to put in a unittest, in the same module (but outside the class - as you've suggested).

Let's also say, the programmer does *not* want the unittest to be able to penetrate the private parts of the class.

If human error creeps in to their unittest, as it inevitably will, then they will not know about this until runtime. How do they get around this problem? I guess, they'll be forced to put the unittest inside the class. But what if, like you, they don't want to?

Something like this below, would actually enhance the value of unittests too, because now the compiler would require your unittest to use the objects public interface (human error cannot creep in now - and people like me won't have to inspect every unittest to see that its programming to the interface):

---------------------
module test;

@safeinterface class Dog
{
    private string noiseType;

    public string makeNoise()
    {
        this.noiseType = "woof";
        return this.noiseType;
    }
}

unittest
{
    Dog d = new Dog();
    d.noiseType = "meow"; // ohhps. human error - lucky I used @safeinterface
                          // compiler will statically enforce this.
}
--------------

On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup wrote:

> Any debate about restoring the rights and autonomy of the class, should not be killed off.
>
> Any programming language that discriminates against the class, encourages class warfare, does not deserve to be called a programming langauge.

Knock it off with the hyperbole language already, this is a programming language not a civil rights movement.

On Tuesday, 22 May 2018 at 13:33:12 UTC, 12345swordy wrote:
> On Tuesday, 22 May 2018 at 03:10:39 UTC, Bjarne Stroustrup wrote:
>
>> Any debate about restoring the rights and autonomy of the class, should not be killed off.
>>
>> Any programming language that discriminates against the class, encourages class warfare, does not deserve to be called a programming langauge.
>
> Knock it off with the hyperbole language already, this is a programming language not a civil rights movement.

The guy is unstable and has gone careening off since I kicked his soapbox... i mean his argument to pieces.