On 21/04/2014 09:49, Lars T. Kyllingstad wrote:
> I often wish "private" meant class private in D.  I know, the usual
> argument against this is that someone who writes a module usually has
> full control of that module, but again, Phobos is an example of the
> contrary.  Each module has at least a dozen authors, even if they aren't
> all listed in the documentation.

I think this is a good argument. True private aids developers when refactoring. Also synchronized classes always have true private members, so it would be better if D could express it instead of changing the meaning of 'private' for them.

> I also know it's never going to happen due to the amount of code
> breakage it would cause.  But maybe we could extend the syntax a bit?
> E.g. "private(class)" or "class private"?

Perhaps the following would work:

* Add 'module' as synonym for 'private'
* Add '@private' for true private access
* Deprecate 'private' after some years

I doubt this would be popular due to churn, but I would support it.

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.

On Tuesday, 22 April 2014 at 06:39:47 UTC, Jacob Carlborg wrote:
> I'm almost exclusively organizing with one class per module and a deeper hierarchy of packages. Not saying that is the ideal solution.

That's what i've started to do in a recent project and then use the special 'package.d' file to provide a package. Sometimes you may have a couple of related classes or enums in each file too but only if they need to be friendly with the main class. This way is much more clear and neat.