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

Atila Neves atila.neves at gmail.com
Fri Nov 2 11:50:05 UTC 2018


On Thursday, 1 November 2018 at 18:30:33 UTC, 12345swordy wrote:
> On Thursday, 1 November 2018 at 17:58:34 UTC, Atila Neves wrote:
>> On Thursday, 1 November 2018 at 16:19:57 UTC, 12345swordy 
>> wrote:
>>> On Thursday, 1 November 2018 at 14:17:13 UTC, Atila Neves 
>>> wrote:
>>>> On Monday, 29 October 2018 at 23:15:58 UTC, 
>>>> unprotected-entity wrote:
>>>>> On Monday, 29 October 2018 at 15:50:56 UTC, Jonathan M 
>>>>> Davis wrote:
>>>>>>
>>>>> It's not (just) that I don't like it, it's that I don't 
>>>>> like not giving the programmer the tool to better 
>>>>> encapsulate their code (specifically classes) *within* a 
>>>>> module.
>>>>
>>>> You don't need to protect code in your module from other 
>>>> code in your module. If you do, put them in different 
>>>> modules.
>>> That typically involves creation of files, which is not 
>>> always ideal if you are working with code that is 
>>> considerably small.
>>
>> If the code is considerably small you don't need private. You 
>> don't need any good engineering principles at all, use goto to 
>> your heart's content. It just doesn't matter.
> Not the point. We talking about encapsulating code which 
> involves creation of another modules which always involved in 
> creation of another file. Which is not always good solution if 
> your code is remarkably small.

That wasn't my point either. My point is that if your code is 
"remarkably small", you don't need _any_ good engineering 
practices. You don't need encapsulation, abstraction, 
maintainability, anything. It's like killing an ant with a 
bazooka.

Pretty much nothing you do in a 100 SLOC codebase matters unless 
it's a library, in which case the only important thing is the API.

>> That makes as much sense to me as introducing a keyword to 
>> protect a class from itself.
> It the equivalent of building another house to give your new 
> child its own room, when you can simply assign a room in the 
> house that you already have.

That's the beauty of code, isn't it? Building another house is 
easy so why not? If in real life I could conjure a whole new 
house in less than a second for a child to live in, why wouldn't 
I???


More information about the Digitalmars-d mailing list