Re: Newbie Q: Class Privacy (or lack of)
- From: Marc 'BlackJack' Rintsch <bj_666@xxxxxxx>
- Date: Fri, 28 Jul 2006 10:12:31 +0200
In <44C9B607.B0FFBAC3@xxxxxxxxxxxxxxxxxxx>, Steve Jobless wrote:
Bruno Desthuilliers wrote:
Steve Jobless wrote:
But what about adding a method to the class? Am I supposed to ask "Is
anyone using name xxx?"
assert 'xxx' not in dir(SomeClassOrObject)
The class may be used by developers I don't
even know and some of them may be on the other side of the planet...
How could this be a problem ? What's added/changed at runtime in a given
app doesn't impact the source code.
Say you are a 3rd party library developer. You can tell your customers
to check dir(MyClass), but you can't enforce it. Even if they do, just
updating your library could break THEIR code. It's not your fault, but
you have to patiently diagnose their problem and nicely tell them it's
their fault.
But if they mess with the objects of your library I expect them to check
first if this is the cause of the failures. They hopefully *know* where
they crossed the line into my implementation. Because adding a method to
a "foreign" class is semantically the same as writing it directly into the
source code of that library.
This should be done only when it's really needed and it should be
documented. Just because it's possible doesn't mean it's the way to solve
most problems that may be better solved by inheritance.
Just one example : suppose you're working with a framework. Suppose
you'd need to customize some objects (including classes - Python classes
are objects too) of the framework, but the framework has no hook for
this and you definitively don't wan't to bother patching the code and
maintaining your own branch.
<IMHO>
Maybe it's cultural. But one aspect of OO is that you only need to know
what the object does (interface), but you don't have to (and better not)
know how it does (implementation). This is important because the class
implementor can enhance and/or optimize the class without breaking
users' code as long as the interface is compatible. (This is why most,
if not all, instance variables should be private. You can use
__getattr__/__setattr__, but they don't always work.) If you need to
customize a class, you should sub-class it using the public interface of
the base class. You better not mess with it from the outside because
updating the class can break your code. Unfortunately, I don't see a way
to separate interface from implementation in Python. So, it may not make
much difference whether you subclass it or hack it from the outside.
It makes a difference. If you subclass the chances that your modification
breaks if the implementation of the library class changes is much lower.
Pythonistas expect a programmer to know this and act accordingly.
Separating interface and implementation is done by naming conventions in
Python. If a name starts with an underscore it's not part of the API.
I was hoping someone shows me a compelling reason to sacrifice the
safety, but I don't hear much.
It looks pretty good as long as it is used by a small
group, especially for a small project. (Or Python is meant just for such
projects?)
Please prove that the safety is sacrificed to the extent that you fear.
This "if you don't have `private`, everything starts to fall apart and
explodes right in your face if the project starts to get bigger" arguments
aren't backed by empirical data either but often seems to be just learned
by heart in Java and C++ courses.
Ciao,
Marc 'BlackJack' Rintsch
.
- References:
- Re: Newbie Q: Class Privacy (or lack of)
- From: Steve Jobless
- Re: Newbie Q: Class Privacy (or lack of)
- From: Steve Jobless
- Re: Newbie Q: Class Privacy (or lack of)
- From: Bruno Desthuilliers
- Re: Newbie Q: Class Privacy (or lack of)
- From: Steve Jobless
- Re: Newbie Q: Class Privacy (or lack of)
- Prev by Date: Py2exe for packaging installers?
- Next by Date: Re: a print bug?
- Previous by thread: Re: Newbie Q: Class Privacy (or lack of)
- Next by thread: Re: Newbie Q: Class Privacy (or lack of)
- Index(es):
Relevant Pages
|
