On Feb 1, 1:50 am, Marc 'BlackJack' Rintsch <bj_...@gmx.net> wrote: > On Sat, 31 Jan 2009 15:28:14 -0800, thmpsn.m.k wrote: > > On Jan 31, 2:27 pm, Christian Heimes <li...@cheimes.de> wrote: > >> Do you honestly believe that C++'s private members are really private? > >> Privateness is only enforced during parsing time. Nobody can stop you > >> from messing around with header files or memory. You can still access > >> and modify private members but it's all messy and ugly. Even C# and > >> .NET don't stop you from doing nasty things from unmananged assemblies. > > > I don't know how you would do it in C# (or Java for that matter). > > In Java you can use reflection to get your fingers on private fields. > > > In C++ you can play with pointers to "get at" some memory location > > somewhere in the object. > > [Snipped pointer fiddling explanation] > > So: Sometimes it may work, usually it will be unsafe and/or non- > > portable, and in most cases the procedure will look complicated. > > 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 (b) the members are preceded with neither "private:" nor "public:" nor "protected:", in which case they'll be private by default (c) someone else suggested that point (b) is defeated by defining a macro named "class" as "struct", which will make members public by default; well, we can do something similar to what we did in point (a): define a macro, say, "CLASS", as "class", and use CLASS the define the class 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. 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! -- http://mail.python.org/mailman/listinfo/python-list
