Why do private member variables behaved like protected in the same module when creating deriving class?

unprotected-entity unprotected-entity at gmail.com
Thu Nov 1 23:23:55 UTC 2018


On Thursday, 1 November 2018 at 16:32:23 UTC, H. S. Teoh wrote:
>
> Java also enforces, by policy, the creation of a separate file 
> for every public class.  This is no different.
>
>
> T

If I wanted Java in D, I already have Java - which does a better 
job at being Java, than D.

Also, I do not consider a single class, to be such a big bucket 
of code, that it should necessarily be a module all of it's own.

Again, D kind forces this onto anyone coming from a class based, 
oop langauge - but only because D won't all private to be private 
in modules. And I don't know many class-based oo programmers, 
that find that acceptable.

The only options D give such programmers, is:

(a) stiff, stick to you current language if you don't like how D 
does it.
(b) make sure you only ever have one class in a module in D.
(c) stop thinking like that, and start thinking like D apparently 
wants you to think.

I don't believe langauges should force a particular design upon 
the programmer.

I'm not big fan of inheritance either, despite it being a valid 
and useful way to architect your solution. I like self-contained 
classes - and would like to have more than one self-contained 
class in a module. Java requires that only one can be public, 
which is a design pain point for me, that forces you into Java 
like design.

It is not too much to ask, in my opinion, to have a 'strict 
private' like concept in D, which does everything private does 
(so it's not a breaking change), but additionally, keeps it 
private within the module too.

That would also give the programmer, the option to write 
unit-tests that cannot access private parts. That surely would be 
a good thing (again, it's an option for the programmers - it's 
not forced upon them).

Argue about how that should be done (syntax), fine. But telling 
programmers they only have the 3 options mentioned above, is 
kinda sad.

Those do don't like the change, are really not that affected. 
They can just keep doing what they've always done. A good option 
for the syntax, would ensure it's immediately clear, that the 
programmer want their private parts, to remain private.

How difficult/complex that would be, to actually implement, well 
that's a discussion that would interest me. But nobody is 
benefitting from just saying 'no' all the time.

It's not about securing your code from other code in the module.

It's about clean architecture.




More information about the Digitalmars-d mailing list