Russ P. a écrit :
On Jan 18, 9:22 am, Bruno Desthuilliers
<bdesth.quelquech...@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
attributes.
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
implementation.
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.
--
http://mail.python.org/mailman/listinfo/python-list
