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.
