static and protection

[David Medlock]

Bruno Medeiros wrote:
> David Medlock wrote:
> 
>> Hasan Aljudy wrote:
>>
>>> David Medlock wrote:
>>>
>>>> Tony wrote:
>>>>
>>>> Disclaimer: the OP code seems to be a bug, I am not contradicting that.
>>>>
>>>> Each time I hear things like this I always ask for specific 
>>>> pragmatic examples of strict protection benefits outside of simple 
>>>> namespace-clash issues(which also mean IDE code completion).
>>>>
>>>> I've yet to see a good example in which strict protection attributes 
>>>> prevented any defects.  Thus far this is a sky-is-falling issue, 
>>>> with very little real practical evidence.
>>>
>>>
>>>
>>> It's not obvious in small programs, but it becomes crucial in large 
>>> projects, and even more crucial in projects with millions of lines of 
>>> code.
>>>
>>
>> Most of my projects are in the 10-50k LOC range, with a few dipping 
>> 100-200k.   With projects of large size, the interfaces between the 
>> components needs to be a component itself.
>>
>> A.C(B)
>>
>> should be (where C is an object)
>>
>> C( A, B )
>>
>> No amount of protection in A or B will help there.
>>
> 
> Why not? You can still protect C, even though it's an object/class and 
> not a method, isn't it so?
> 


What I mean is something like this(sortof strategy pattern):

// begin simplified example

class A { int a; void foo(B b) {...}; }
class B { int b; }

Multiply the number of A descendents and it gets messy, especially with 
a large tree.

Since the implementation of A is generally constant, I usually end up 
refactoring to:

class foo {
   void call( A a, B b );
}

This class must use the members of A and B.  In C++ it would be a 
friend, but since its functionality is local, it doesn't make any 
difference at all what the modifiers are for the data members of A and B.

Any problems you have will be in foo, no matter whether you use accessor 
methods or just public variables.

In all of this I am speaking of sub-classing, not sub-typing.  There is 
a very real reason to hide private methods, but the typical usage of 
inheritance which gets into trouble is using it as a mixin or shared 
functionality mechanism.  This usage of inheritance is *exactly* what 
protected access is for, base functionality exposed at the class level 
for re-use.

-DavidM