Wed Oct 17 - Avoiding Code Smells by Walter Bright

Paul Backus snarwin at gmail.com
Mon Nov 5 08:19:03 UTC 2018


On Monday, 5 November 2018 at 05:55:02 UTC, unprotected-entity 
wrote:
> ok. Now, what are your options then (assuming you want an 
> independent type)?
>
> (option 1) define one encapsulated type, per module.
> (option 2) have a means for type independence within a module - 
> i.e. selective hiding.
>
> D only gives you one choice here, not two.

Is having two choices really better than having one choice?

When you only have one choice, you don't have to make any 
decisions. When you have two choices, you are *forced* to make a 
decision, whether you want to or not.

That can be a good thing, when the decision you're making is 
meaningful--for example, when you're deciding whether to use GC 
or manual memory management. But when the decision you're making 
is meaningless--for example, when you're deciding whether to 
indent with tabs or spaces--it's just a waste of time. It doesn't 
matter which you choose, but you're forced to make a decision 
anyway. (Or, even worse, your entire team is forced to waste time 
*agreeing* on a decision together.)

When it comes to encapsulation, it makes no *functional* 
difference whether you achieve it by putting all your types into 
separate modules, or by using something like `__private`. The end 
result is the same either way. The only reason to prefer one over 
the other is personal taste--in other words, it's a matter of 
style, just like tabs vs. spaces.

Personally, I don't think there's anything wrong with preferring 
`__private` over separate modules, just like I don't think 
there's anything wrong with preferring spaces over tabs. But I 
think being forced to make meaningless decisions is bad no matter 
what you prefer, and because of that, I don't think `__private` 
should be added to D.


More information about the Digitalmars-d-announce mailing list