Prothon gets Major Facelift in Vers 0.1.0 [Prothon]

[Duncan Booth]

"Neil Hodgson" <nhodgson at bigpond.net.au> wrote in
news:vY8sc.6634$L.2827 at news-server.bigpond.net.au: 

>    Technique 2:
> 
> #define private public
> #include <C_definition.h>
> #undef private
> 
>    C c;
>    c.x = 1;
> 
>    In both of these it is obvious that the encapsulation rules are
>    being 
> broken which is exactly the same situation as when someone uses the
> mangled name in Python. I have used technique 2 in production code
> where a library could not be altered and access to private methods was
> required. 
> 

To me, this is one of the greatest arguments against use of private 
variables in C++.

I have also been reduced to using exactly this technique when faced with a 
library where the implementation was visible to the whole world, but the 
public interface didn't make enough of it accessible. I can think of 
numerous times when private names have been a real pain, but I have never 
had a problem which would have been solved by making a public name private.

In C++ private doesn't hide the implementation at all, it simply restricts 
access. In Python, the __ prefix for private variables does some 
(rudimentary) hiding but doesn't really restrict access.

In a language where the implementation can be hidden there may perhaps be 
reason to use private although defining the public part as an interface is  
a better way to go. Even in C++ you can use interfaces to hide the 
implementation, and for those (rare) cases where you need to get into the 
internals you may safely cast to the specific implementation and get at its 
internals (provided nobody used private) without having to resort to 
unsightly kludges. Sadly many C++ programmers fail to grasp this concept.