Does Python really follow its philosophy of "Readability counts"?
bruno.42.desthuilliers at websiteburo.invalid
Mon Jan 19 16:13:22 CET 2009
Russ P. a écrit :
> On Jan 18, 9:22 am, Bruno Desthuilliers
> <bdesth.quelquech... at free.quelquepart.fr> wrote:
>> Properties by themselves are not the problem, quite on the contrary - as
>> you say, they actually help wrt/ encapsulation. What breaks
>> encapsulation is *automatic generation* for properties for *each and
>> any* implementation attribute. Might as well just makes them all public
>> attribute then.
> Let me correct my statement about the automatic generation of
> properties in Scala: it is only for public attributes, not all
I must be missing the point : if it's a public attribute, it doesn't
need a "property" ? I guess we use the same words for different things here.
> Getting back to the bigger point, I will gladly agree with you that
> data hiding is not a magic bullet that will eliminate all bugs. The
> idea that I or anyone else said that, however, is a red herring. Data
> hiding is just one safeguard in a portfolio of safeguards that can
> *help* to prevent certain kinds of bugs
s/data-hiding/encapsulation/ and I'll wholefully agree.
> as well as deliberate acts of
> sabotage or fraud.
I definitively wouldn't bet my ass on language-level access restriction
to protect software from fraud or sabotage.
> When you have a tough problem to solve, you need
> all the help you can get.
As far as I'm concerned, *enforcing* access-restriction is of no help.
> You keep saying that if you hire competent, trustworthy developers,
> you don't need data hiding.
Yes. And I also think that trust (and even - to a certain extent -
competence) is better built on trust than on distrust. When treated as
an irresponsible morons just barely able to type code, most peoples tend
to become just that : code-monkeys.
> Well, maybe, but when you have a team of
> dozens or hundreds of developers, your chances of avoiding any bad
> ones is zero for all practical purposes.
I don't know how many developpers work for google, but I bet there all
smart enough to not need enforced access restriction. Very few people
have a burning desire to shoot themselves in the foot, you know.
Take some not-that-trivial projects like Zope/Plone. There are quite a
few lines of code involved, and quite a lot of programmers worked on it.
Some of them being very average joe programmer FWIW. Guess what ? From
experience, it JustWork(tm). Granted, this is not a critical system -
but that's not the point here. The point is that _from experience_, most
programmers are wise enough to avoid doing stupid things.
> And even if all your developers were excellent, data hiding would
> still be a convenient mechanism to simplify their jobs so they can
> focus on higher level problems
Sorry, but this makes no sense. How could the lack of
*language-enforced* access restriction makes anything more complicated ???
> -- and not have to rely on an ugly
> naming convention.
And here we are, finally : *you* don't like this convention (and we've
aready been thru that discussion IIRC).
Guess what ? As far as I'm concerned, I just *love* this convention.
Because I *never* have to ask myself if some attribute is interface or
> Now, if developers become careless because they think data hiding will
> save them, then that would be a problem.
If you believe data-hiding will protect your code from fraud, sabotage
or any other malevolence, then you already have this problem IMHO.
> That much I will concede. But
> I doubt that happens much.
More information about the Python-list