On 14/03/2018 12:19 AM, psychoticRabbit wrote:
On Tuesday, 13 March 2018 at 08:29:42 UTC, Alex wrote:
package myPackage;
public class Main {
public static void main(String[] args)
{
System.out.println("Hello World!");
myClass c = new myClass();
c.myPrivateClassMember= "wtf";
System.out.println(c.myPrivateClassMember);
}
private static class myClass
{
private String myPrivateClassMember; // private does not mean
private anymore??
}
}
´´´
(may the forum forgive me :p )
But a class and its inner classes together, can be still be reasoned
about locally.
With 'modules', the boundaries of what 'local' means, becomes more and
more fuzzy, as the module gets longer and longer, and more and more
complex.
In those circumstances, it becomes much harder to reason locally about
the correctness of a class.
And a D module can go on..well...for ever.....
I would still prefer that classes within a module, at least have a
capacity to specify access privileges to objects in the same module,
rather than just trusting everything in that module, without exception.
Ah yes.
You're completely correct if you subscribe to Adam's and ketmar's file
sizes expectation.
A D module and package is one level of abstraction. If that level of
abstraction starts to fill up and gets large, you split it up.
My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good
reason to stay together).
This makes each file to be very right down to the point and do nothing else.
You should be doing this no matter the language IMO. Just the difference
is in Java only one class is publicly accessible per file. Nothing stops
you from doing that here either.
