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