Quoting thmpsn....@gmail.com: > > Or ``#define private public`` before including the header files. Which > > doesn't look complicated to me. > > Which again won't always work, if: > > (a) the header defines another macro, say, "PRIVATE", as "private", > and uses PRIVATE to declare private members
[other reasons deleted] So, can I assume that most of the C++ code out there defines "PRIVATE" as "private" just to prevent breaking the encapsulation _intentionally_? Somehow I find that hard to believe. > Anyway, it doesn't matter. We're losing the point here. The point is > that language support for private access, by disallowing user access > to private data, provides an unambiguous information hiding mechanism > which encourages encapsulation. And Python, by providing a well defined convention of what is inaccessible, provides an unambiguous information hiding mechanism wich encourages encapsulation. > Python's approach, however, which is > only a naming convention rather than a language feature, merely TRUSTS > the programmer not to break encapsulation. And sure, if we're all good > programmers, everything will go well and we'll end up with an > organized application. But the danger is still there: at any given > time, we COULD break encapsulation! And what's the problem with that, exactly? I can break encapsulation... and I can jump off my roof. Why do _you_ care about what _I_ can do, as long as it doesn't harm _you_ (or others)? If you are worried about you breaking encapsulation, then just don't do it. It is not hard. Whenever you find yourself typing "._somehting", just check that the string before the dot is "self". If you can't trust yourself to access only the well identified "public" attributes, how can you trust that you will just not make "public" a private attribute anyway? -- Luis Zarrabeitia Facultad de Matemática y Computación, UH http://profesores.matcom.uh.cu/~kyrie -- http://mail.python.org/mailman/listinfo/python-list
