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

theoutlaw theoutlaw at hotmail.com
Sat Nov 3 02:07:37 UTC 2018


On Friday, 2 November 2018 at 15:18:05 UTC, Q. F. Schroll wrote:
>
> How about public and private unittest?
>
> ...A private ...unittest, on the other hand, tests private 
> state....

The problem is, that there is NO private state within a module.

Not even for struct.

Zilch! nəTHiNG!

Now, how many who want private state for their struct type, are 
going to go down the path of putting 'one struct per module'. But 
those of us who want it for a class, are told to do just that.

If only the programmer had a tool to define accessibility for a 
type, that would apply to accessibilty not just for code outside 
the module, but also to code within the module (but outside of 
that declared type), then:

-------------
class Test
{
     __private int Value;
}

unittest
{
     T t = new T();

     t.Value++; // No. it's private - so not accessible outside of 
the module.
                // No. it's also __private - so not accessible 
outside the type
}

------------

Anyone who argues that this syntax would make the language too 
complex, and therefore we should avoid any further discussion, 
cannot be take seriously.

On the otherhand, whether the actual implementation of such a 
feature, is doable, and workable with the language as a whole, I 
wouldn't know - and that is worth a discussion.



More information about the Digitalmars-d mailing list