On Thursday, 8 November 2018 at 09:53:59 UTC, TheFireFighter
wrote:
well you could say the same about pointers. but..what happens
when a large number of programmers start using pointers?
I don't see the parallel between pointers and class-private.
But my argument actually is less about bugs, or the potential
for bugs (although that potential obviously exists). My
argument is more about the 'untyped' nature of the D module.
That's a shame, I think the bug-argument is the stronger one.
Now, if you're one of those that object to the use of classes
(and there are many in the D forums), then you would already be
biased towards dismissing my argument, and don't mind at all if
the class is subject to humiliation. I would prefer you refrain
from the discussion, if such bias is going to be used to
shutdown the argument.
My guess, based on my experience, is that bad coders will seek
the shortest path to something that works. So if they need to
quickly access a class-private member in the module they're
working on, they'll remove the private attribute. But I don't
know, I'm biased like everyone. I haven't worked in the same
setting as you. That's why I'm really interested in hearing your
perspective. I don't have a strong opinion on the importance of
visibility attributes within a module, so I'm interested in
hearing strong arguments from you. But so far, your arguments
boil down to:
- Avoiding justification - "Obviously" "I don't have to explain
this" "Any decent programmer knows this"
- Appeal to fear - "Just wait for all the problems that come in
the future!"
- Appeal to feeling - "Classes are naked, humiliated, their
private parts are violated. That's so clearly wrong."
I don't find such arguments strong. If they were, you could also
justify adding the @noloops attribute as I jokingly did in my
previous post.
Lets be clear. My argument (not my DIP - as there is none) is,
that it can only strengthen D, if D allowed the programmer the
option (just the option) to ensure that a class wasn't
subjected to such humiliation, when there is other code in the
module besides that class.
That sounds like "I just want there to be the option for
aggregate value types... without using struct.". The question
this raises is why the current solution is so problematic.
I do not understand the motivations of those that reject such
an argument.
Do you agree that language additions add a lot of weight? If yes,
then it's simply the fact that people don't think your suggestion
bears that weight because it's already possible to do what you
want in another way.
