static and protection

[David Medlock]

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.

> I think the dmd compiler is a good example.
> Don't you see how Walter spends more time fixing bugs than adding new 
> features?!
> If you look at the source code you can understand why.
> I must say that I'm amazed how he can maintain the source code of the 
> compiler!!
> However, I think that if he'd used proper object oriented model for the 
> compiler, less bugs will need to be fixed, and maybe v1.0 would've been 
> ready along time ago!
> 

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.

>>
>> 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.

> 
> 
>>
>> 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 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.

Cheers.
-DavidM