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