Does Python really follow its philosophy of "Readability counts"?
Russ.Paielli at gmail.com
Tue Jan 20 07:00:47 CET 2009
On Jan 19, 9:21 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> Bruno Desthuilliers <bdesth.quelquech... at free.quelquepart.fr> writes:
> > The failure was because a module tested, QA'd and certified within a
> > given context (in which it was ok to drop the builtin error handling)
> > was reused in a context where it was not ok. And the point is exactly
> > that : no *technology* can solve this kind of problem, because it is a
> > *human* problem (in that case, not taking time to repass the whole
> > specs / tests / QA process given context change).
> In this case it does nothing at all to support your arguments about
> the helpfulness or lack of helpfulness of strong encapsulation. You
> may as well say that antibiotics are medically useless because they
> won't stop anyone from getting killed by a falling piano.
He says that "no *technology* can solve this kind of problem."
First of all, I'm not sure that's true. I think technology *could*
have solved the problem -- e.g., Spark Ada, had it been properly
applied. But that's beside the point. The point is that the problem
had nothing to do with encapsulation. The rocket failed because a
conversion was attempted to a data type that could not hold the
required value. Am I missing something? I don't see what that has to
do with encapsulation.
The logic seems to be as follows:
1. Ada enforces data hiding.
2. Ada was used.
2. A major failure occurred.
Enforced data hiding is useless.
If that reasoning is sound, think about what else is useless.
More information about the Python-list