On Jan 15, 12:21 pm, Bruno Desthuilliers <bdesth.quelquech...@free.quelquepart.fr> wrote:
> Once again, the important point is that there's a *clear* distinction > between interface and implementation, and that you *shouldn't* mess with > implementation. If you "*shouldn't* mess with the implementation", then what is wrong with enforcing that "shouldn't" in the language itself? Why leave to coding standards and company policy what can be encoded right into the language? Why leave to humans (who are known to err) what can be automated relatively easily? Isn't that what computers are for? >But what, some people think programmers are stupid, and > so they hire stupid programmers, so they need b&d languages to protect > stupid programmers from themselves - which just doesn't work, since > *nothing* is idiot-proof. Heck, how many Java "OO" programs with dumb > getter/setter pairs for _each and any_ attribute ? Hey, I share your distaste for Java and C++. All those "setters" and "getters" are a kludge. I think Python "properties" are a major step forward here. Just for fun, I checked to see if Scala has properties. Guess what? Not only does it have them, but they are generated automatically for all member data. That's even better than Python properties! > > As I said before, enforced encapsulation may not be appropriate for > > every application, but it is definitely appropriate for some. > > No. It is appropriate for dummy managers hiring dummy programmers. The > project's size and domain have nothing to do with it. Let me try to be very clear here. We are dealing with two separate but related issues. The first is whether data hiding should be added to Python. The second is whether data hiding provides any net benefit in *any* language. As for whether data hiding should be added to Python, I am not arguing one way or the other. I am merely saying that it is worth considering. Whether it can be added without screwing up the language, I don't know. If not, then so be it. That just limits the range of domains where Python is suitable. As for whether data hiding provides a net benefit in any language, it certainly does for large programs and for safety-critical programs. For large, safety-critical systems, it's a no-brainer. I think data hiding can also provide net benefits for medium-size and even smaller programs, but lets just consider large programs, so I can shoot down your argument that data hiding provides no benefit. I like to use the example of the flight software for a large commercial transport aircraft, but many other examples could be given. How about medical systems that control radiation therapy or chemotherapy? How about financial systems that could take away your retirement account in 1.5 milliseconds. Or how about the control software for the strategic nuclear arsenals of the US or Russia? When you consider the sea, air, and land-based components, I'm sure that's one hell of a lot of code! So let's take the airplane example. Boeing and its contractors probably has hundreds of programmers working on millions of lines of code. If they believed you, they would abandon enforced data hiding, and programmers would have much more discretion to screw around with code that they don't work on directly. An FMS programmer could perhaps decide to change the parameters of the engine controls, for example. To prevent that sort of thing from happening, the management could decree that henceforth all "private" variable names will start with an underscore. Problem solved, eh? Wait a minute. You yourself have stated several times that those stupid library developers can never predict what the client will actually need. So some FMS guy named Bruno decides that he knows better than the engine group what a certain engine parameter should be. Or he decides that his code needs to know the value of that parameter, so he just goes ahead and reads it. No harm done, eh? But wait a minute. Half the programmers did the same thing, and now we have a spaghetti mess on our hands. So now management needs to implement a costly, bureaucratic program to find all such accessing of private data and correct it -- before a disaster occurs in flight. So they have meetings and assemble a data-hiding enforcement team that meets twice each week and constantly looks over every programmers shoulder. Wait a minute, wouldn't enforcement of data hiding by the programming language be preferable to a huge bureaucratic program? I sure think so. And thankfully, so does Boeing and anyone else who has a clue about large-scale software production. Now, let's talk about a data access violations in the nuclear missile launch software. Oh, yes, I'm sure the leading underscore convention is more than sufficient! Wake up, dude, and quit spouting bullsh*t! > > Not > > every door needs a lock, but certainly some do. > > You only need locks when you don't trust your neighbours. Yeah, if you live in Nome, Alaska. Also, have you ever heard the expression "locks keep honest people honest"? I spent *way* too much time on that post. I really need to quit spending my time refuting the baloney that passes for wisdom here. -- http://mail.python.org/mailman/listinfo/python-list
