[fpc-devel] strict private

[Marco van de Voort]

In our previous episode, Thaddy said:
> > IMHO strict private has nothing to do with strictness, except for the first
> > word. It has to do with micromanaging visibility, something I do not agree
> > with, not in the least because the exact use is highly a matter of taste.
> >
> > I would prefer to keep it far from FPC codebases.
> >   
> Do you mean you agree with the design flaw in the original object pascal 
> specification from Borland? Plz explain...

First, I'm not sure it is a bug/flaw. Second, I'm sure I don't want more
visibility levels.

> IIRC even Anders admitted that simply separating interface from 
> implementation was based on only partial knowledge of the OO paradime 
> and has corrected that oversight in C#.

Is that the same Anders that allowed umpteen directives, modifiers etc in
C#? No wonder he has no problem with it :-)

> IMHO "strict" is a good thing and by design, albeit not implemented soon 
> enough in history

Well, a case could have been made then, but IMHO changing it is no option
out of compatibility, and adding another level is IMHO worse then the actual
problem.

> Unlimited visibility in the implementation section 
> makes for unreliable programming and therefore should be considered a 
> bug if not a potential lethal and stealthy source for those insects.

IMHO that is an opinion, not a fact. I could counter that more levels in
visibility lead to more errors in visibility.

However my consideration originate more from the discussions about other
post D7 modifiers that try to micromanage visibility. My own end conclusion
were that while they give the feeling of control and safety, they don't
really add to security, specially because a perfect visibility can only be
decided in retrospect, when all applications are known.