static and protection

[Hasan Aljudy]

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.

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 Walter, that is just my opinion .. I know it is offensive, but 
.. oh well <g> ))

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



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

> I hope Walter keeps "all module classes can see each other".

I wish at least that he'd make it require an explicit statement.

> 
> -DavidM
> 
> "Wherever there is modularity there is the potential for 
> misunderstanding. Hiding information implies a need to check 
> communication." - Alan Perlis

I'm all against information hiding.
I'm all for cohesion.