Sealed classes - would you want them in D? (v2)

[Sjoerd Nijboer]

On Monday, 21 May 2018 at 14:30:21 UTC, KingJoffrey wrote:
> On Monday, 21 May 2018 at 13:39:12 UTC, Sjoerd Nijboer wrote:
>>
>> While you might say that a unittest shouldn't acces private 
>> members and only public members, there are plenty of testcases 
>> where one would want to write a unittest to set a given 
>> variable via public function and then test if the appropriate 
>> private fields are properly set. While this sounds like a 
>> trivial usecase I believe it to be a verry big one in practice 
>> since it removes a lot of boilerplate code from your 
>> unit-tests, together with exposing the innards of a class's 
>> implementation to the outside world just so you can unit-test 
>> it.
>
> I have to ask, why isn't that unittest your talking about, 
> within the scope of the class? Why is it outside the class, 
> testing private innards of the class?
>
> I have trouble getting my head around this.

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.

>> The last point is something I don't like about OOP + TDD in 
>> languages like C# or java and I think D has (accidentally) 
>> solved this in a beautiful way, and I would dislike to see 
>> this feature go.
>
> I'm not sure I understand this. You mean you don't like 
> 'private'?
>
> You think an object doesn't have a right, to privacy?
>
> Are you one of those facebook employees?
>
> And who suggested getting rid of anything?

Nope, I'm simply a bystander who sees lack of class scope as a 
"feature" of D that is usefull in some cases while not hurting 
idiomatic OOP as long as you only define a single class (+ 
unittests) inside a module.
If you want that too but still want static functions outside 
classes, you can mix in C# extension methods paradigm into D. 
Which is why I don't see any reason to add this.

But besides that, I just wanted to put forward that we don't need 
to do `private(this)` or `private(className)` if this ever became 
a language feature because it would be confusing as to why it 
could bind to class or struct scope but not to any other scope 
and might as well introduce a new keyword which isn't regularly 
used in other languages like `sealed` but could instead come up 
with a new one.
I felt that my response was incomplete whitout adding I think 
that the concept of a class private in D would not be a good idea.

Also, I would verry much much like it if you would not resort to 
comparing me to "one of those facebook employees." It's just 
setting a mood for the conversation which no one likes, 
regardless what anyone thinks about facebook employees.