On Jan 19, 7:13 am, Bruno Desthuilliers <bruno. 42.desthuilli...@websiteburo.invalid> wrote:
> 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. Yes, you are missing more than one point. Scala automatically converts public data members into properties, apparently to save the programmer the trouble of doing it manually. If you are interested, I'm sure you can find publicly available information on it. > I definitively wouldn't bet my ass on language-level access restriction > to protect software from fraud or sabotage. You're missing the point here too. I'll try one more time to explain it. Access restriction enforced by the language is just one safeguard among several that are usually available. I think the lock analogy is very appropriate here. Think about door locks. Would you "bet your ass" on them to keep you secure? Of course not. You might also have a firearm or a dog. But even if you don't have those, you surely have a police department, and surely they carry guns. Because you cannot "bet your ass" on door locks for your security, does that mean you just abandon them altogether? Maybe so, if you live in a very remote place, but most people still seem to think they need locks on their doors. Well, think of access restrictions enforced by the language as analogous to door locks. Let's take the analogy a bit further. Suppose you work in a secure building with strict access control, and everyone in the building is "trusted" (whatever that means). This situation is analogous to a group of "trusted" developers working on a project together. Would you feel comfortable having no locks on the doors? Maybe you would, but I wouldn't. I wouldn't want to just let my co- workers, trusted or not, have access to all my personal stuff. And what if I need to store something of value from time to time? They may be honest, but why even tempt them? What if one of them decides he needs to borrow my favorite Python book while I'm gone, then forgets to return it? But what if you don't want your door locked? Well, you have the option of not using your lock. You can get your way whether the doors have locks or not. But if I want mine locked, and no locks are available, I can't get what I want. When you say that a language should not even have access control available, you are essentially saying that you should get your way -- and to hell with anyone who disagrees with my way. > 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. That may well apply in some environments, but it certainly does not apply in all environments. It certainly does not apply in a defense contracting environment, or a financial software development environment, to give just two of many possible examples. Maybe you don't personally care about such environments, but who are you to decide what environments Python should or should not be suitable for? > 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 would data hiding have impeded those projects? Or could it perhaps have helped? I don't know, but I don't think you can simply assume it would have been a net minus. I know for fact that the strict access restrictions in Ada were indispensable in the integration of the flight software in the Boeing 777, for example. Without them, they'd probably *still* be trying to get it right! > > 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 ??? Because it forces humans to check for access restrictions when the language could do it. > > -- 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. If you like it that much, you would be perfectly free to continue using that convention even if access control was enforced. > > 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. I addressed this red herring above. -- http://mail.python.org/mailman/listinfo/python-list
