Wed Oct 17 - Avoiding Code Smells by Walter Bright

[Dennis]

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.