is python Object oriented??

thmpsn.m.k at gmail.com thmpsn.m.k at gmail.com
Sun Feb 1 11:52:35 EST 2009


On Feb 1, 1:50 am, Marc 'BlackJack' Rintsch <bj_... at 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... at 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!




More information about the Python-list mailing list