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

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Nov 1 17:14:51 UTC 2018


On Thu, Nov 01, 2018 at 04:58:07PM +0000, 12345swordy via Digitalmars-d wrote:
> 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.
> So what? I thought this is D not Java.
[...]

Yes, and I'm glad I can (mostly) get away from Java in my current
Android project, thanks to cross-compiling with LDC. :-P

But the point is that it's not all that onerous to have the file/module
as the unit of encapsulation. It's not as if your modern filesystem
would die or suffer severe performance problems if you have a couple of
extra files in your source tree.  And any competent IDE / code editor /
build system should have no problems dealing with an extra file or two,
so I'm not sure I understand why this is such a big hangup for you.

Code in a module should be written to work nicely with each other in the
first place, and doesn't need to be protected from each other.  If they
do, then just put them in separate files, job done.

And if for whatever reason you absolutely MUST have everything in a
single file yet insulated from each other, there's always the option of
pre-processing your code with an external tool to split them up into
temporary separate files and compile those instead of the file you edit,
then you can have your cake and eat it too -- it will literally not
compile if the code tries to call something it's not "supposed" to.

(Yes, I have no qualms about preprocessing / auto-generating code, even
D code, in my projects. In my current project I have two .d files that
are auto-generated from external data. I *could* have done it in CTFE
with mixins, but that would consume a boatload more of RAM and slow down
compilation by an order of magnitude, so it's just back to the trusty
old writefln to print D code from a utility program and then compile the
result.  Abstract all of that away in your build script, and you won't
even notice it afterwards.  And if your build system can't reliably
handle something like this, you need a new build system.)


T

-- 
Time flies like an arrow. Fruit flies like a banana.


More information about the Digitalmars-d mailing list