andreas at kostyrka.org
Fri Jul 1 18:50:36 CEST 2005
Am Freitag, den 01.07.2005, 08:25 -0700 schrieb George Sakkis:
> > Again, how? Is there a way to force that an external user of my lib can
> > not use my internal data/methods/classes, unless he uses odd compiler
> > hacks?
Well, one could probably argue it the other way. In Python you can at
least prevent Python code to access internals of a C-language module. In
C/C++, anything is just one cast away :)
> so. I never understood how mainstream OO languages expect the designer
> of a class to know in advance that an attribute should be hidden or
> unnecessary to its subclasses by being declared "private" instead of
> "protected". The distinction between public and non-public (private +
> protected) is more understandable, but again python's philosophy is
> "we're all consenting adults here". _single_underscored names just
> flash a "use at your own risk" signal, instead of tying your hands in
> case the original class designer made a wrong assumption.
The problem is, that the classic private/protected/public visibility
tags try to solve multiple problems.
Private: Ok, that's all that's really only for the implementation.
public: Well, that's all for my "customers". Hmm. What if I've got two
kinds of customers? Say a customer like in bank customer, and second
customer that plays the role of the bank employee? oops. One can try to
give a certain kind of customer more access by using protected, but that
forces the developer to subclass.
So basically the data hiding as C++ and Java provide are sensible only
in a limited way. It does little beyond disallowing direct member
variable access. Nothing that couldn't be provided in Python with some
stack hacking and a metaclass. It just happens that by the time on knows
enough Python to be able to implement this kind of stuff, the motivation
to do this kind of stupid tricks is usually gone.
Python provides much stronger "data hiding and modelling" support via
properties and the __getattr__ (and friends) special methods. So yeah,
even if takes some violence to explain it to C++/Java developers, good
python code doesn't have getters and setters ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 196 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
More information about the Python-list