Do non-member functions improve encapsulation in D?

[Dicebot via Digitalmars-d]

On Tuesday, 22 April 2014 at 06:39:47 UTC, Jacob Carlborg wrote:
> On 21/04/14 10:49, Lars T. Kyllingstad wrote:
>
>> Ok, so "any number" was poorly phrased.  What I meant was "a 
>> large
>> number", because in my experience, modules tend to be quite 
>> large.
>> Specifically, they are rarely limited to containing just a 
>> single
>> class.  They often contain multiple classes, along with most 
>> related
>> functionality.  In principle, changing the implementation of 
>> one class
>> can break the implementation of another class!  Now, you may 
>> argue that
>> kitchen sink modules are poor programming style, but it seems 
>> to be a
>> common style, with Phobos being a very prominent example. :)
>
> Phobos is a very bad example of code organizing. I'm almost 
> exclusively organizing with one class per module and a deeper 
> hierarchy of packages. Not saying that is the ideal solution.

I like it much more than class-based privacy for the simple 
reason that I hate classes :) What is really missing here is 
proper `package` protection that is actually usable (can select 
package name it applies to). When it is implemented, you can 
emulate same encapsulation layout by simply replacing classes 
with modules and modules with packages.