Hello
thats excellant !!
On 1/23/09, Russ P. wrote:
>
> On Jan 23, 4:57 am, Bruno Desthuilliers [email protected]> wrote:
> > Russ P. a écrit :
>
> > > As I said before, if you have the source code you can always change
> > > private attributes to public in a pinch if the language enforces
> > > encapsulation.
> >
> > And then have to maintain a fork. No, thanks.
>
> For crying out loud, how many private attributes do you need to
> access? If it's a dozen, then you and your library developer are
> obviously not on the same page. If it's one or two, then it's hardly a
> "fork." Just take note of the one or two places where you needed to
> remove the access restriction and you're done. Heck, you don't even
> need to do that, because you will be warned automatically anyway when
> you get the new version of the library (unless those private
> attributes are changed to public).
>
> > > But if you are working on a team project, you can't
> > > change the code that another member of a team checks in.
> >
> > Why on earth couldn't I change the code of another member of my team if
> > that code needs changes ? The code is the whole team's ownership.
>
> OK, fine, you can change the code of another member of the team. Are
> you going to check with him first, or just do it? The point is that
> changing an interface requires agreement of the team members who use
> that interface, whether on the calling or the implementation side of
> it. If you change interfaces without getting agreement with the other
> team members, you probably won't be on the team for long. And without
> access restrictions, accessing _private is equivalent to changing the
> interface.
>
> > Now and FWIW, in this case (our own code), I just don't need to "mess
> > with internals" - I just just change what needs to be changed.
> >
> > > That is how
> > > enforced data hiding helps teams of developers manage interfaces.
> >
> > I totally fails to find any evidence of this assertion in the above
> > "demonstration".
> >
> > > The
> > > bigger the team and the bigger the project, the more it helps.
> >
> > Your opinion.
> >
> > > Mr. D'Aprano gave an excellent example of a large banking program.
> > > Without enforced encapsulation, anyone on the development team has
> > > access to the entire program and could potentially sneak in fraudulent
> > > code much more easily than if encapsulation were enforced by the
> > > language.
> >
> > My my my. If you don't trust your programmers, then indeed, don't use
> > Python. What can I say (and what do I care ?). But once again, relying
> > on the language's access restriction to manage *security* is, well, kind
> > of funny, you know ?
>
> Are you seriously saying that if you were managing the production of a
> major financial software package with hundreds of developers, you
> would just "trust" them all to have free access to the most sensitive
> and critical parts of the program? Now *that's*, well, kind of funny,
> you know?
>
> Would you give all those developers your password to get into the
> system? No? Wait a minute ... you mean you wouldn't "trust" them with
> your password? But what about "openness"? Are you some sort of fascist
> or what?
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
