static and protection

[Hasan Aljudy]

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.

you mean A is an object and C is a method?
Sorry, I don't quite get what's your point there.

> 
<snip>
> 
> Sorry, but this is conjecture.
> I haven't traversed his source code much but the OOP-equals-better-code 
> isn't borne out in the software industry( where is the overflowing 
> abundance of reusable libraries?)
> Even if I accepted the premise, I seriously doubt protection attributes 
> have caused him a lot of bugs.  Ironically handling all the corner 
> cases(like C++'s friend attribute) probably have.

I have also looked at the source code of the half-life and half-life2, 
if you look at it from the point of view of an OO purist, you won't be 
wondering anymore why steam/HL2 are so buggy and why Valve needs to 
release bug fixes every 2 weeks (I guess you can't relate to what I'm 
saying unless you have played HL2 and used steam).

> 
>>>
>>> Its frankly ridiculous to assume that a programmer working on a 
>>> source file(a module) would be tripped up in his own classes because 
>>> one was private and another was not.  If you cant handle a few 
>>> classes in one source file, I question your programming expertise.
>>
>>
>>
>> "few classes" is an understatement.
>> The complexity of the problems tend to increase overtime.
>> Maybe now you see no point in writing get/set methods for this 
>> variable, or you maybe see no point in making a class for this concept 
>> or that one.
>> However, after a while the complexity is likely to increase. You will 
>> find that you need to privitze that variable and write accessor 
>> methods for it, and you will need to group those functions/variables 
>> in a class.
>> It _always_ happens with me, and I've never written a large-scale 
>> project.
>>
> 
> We are talking about a single module aren't we? The most I would expect 
> to see is maybe 4 or 5 classes.  Any more and you probably need to 
> refactor.

Yup, but if your classes are tightly coupled, refactoring won't be that 
easy!! specially when they get big.
That was my point.

> 
>>
>>
>>>
>>> This seems like OOP-purism versus pragmatism.
>>
>>
>>
>> OOP is a purist paradigm, but frankly, this purism came from 
>> experience, and it's a pragmatic purism, not purism just for the sake 
>> of purism.
>> D claims to support OOP. Well .. it should support it properely.
>>
> 
> That goal implies that OOP is a single set in stone paradigm, it is not.
> 
> see:
> http://www.paulgraham.com/reesoo.html

I learned OOP from an OO purist.
No, I don't mean inheritance and polymorphism, I've known this stuff 
before I got into university. What I'm talking about is what OOP really 
means, the abstract conptual theoretical stuff. Alot of people think 
they're doing object oriented programming, when they are actually not. 
Just because you write classes here and there, it doesn't make your code 
object oriented.

There is no formal definition for oop.
The main thing in OOP is cohesion .. really, if you have 20 uncohesive 
classes, then your code is not object oriented.
Unfortunately not many people realize that, and almost no one in the net 
talks about cohesion in an object oriented context.

> 
>>> I hope Walter keeps "all module classes can see each other".
>>
>>
>>
>> I wish at least that he'd make it require an explicit statement.
>>
> But, we already have an explicit _way_ to do that, separate modules.

That's the opposite of explicit!
explicit means "don't do it unless I say it". If I don't tell you to 
enable module friendship, I don't want to see it!!


> 
> Cheers.
> -DavidM
> 
> 

-Hasan