Hello thats excellant !!
On 1/23/09, Russ P. <russ.paie...@gmail.com> wrote: > > On Jan 23, 4:57 am, Bruno Desthuilliers <bruno. > 42.desthuilli...@websiteburo.invalid> 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
