Reply to thread

Message: [QUOTE="Bruno Desthuilliers, post: 3773324"] Steven D'Aprano a Ã©crit : Obviously and definitively, yes. Not that we are that smart - it's just that computers are totally stupids. The differences between a human and a computer are that 1/ a human can eventually DWIM. 2/ a computer can do what is has been told way faster than any human The first point is being smart. The second is being fast. Not quite the same thing !-) Because : 1/ this is something that can be solved by heavy computations 2/ these computations can be programmed 3/ these compuations would just take too long for a human being to do manually Nope, that's a computer-user joke. 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. Once again, I'm afraid you missed the joke - despite the smiley. Oh, sorry. I was talking about *technical* issues, not about legal ones. IANAL... (snip) Nope, it's hard because C and assembly are very low-level languages where you have to micro-manage each and everything. This has nothing to do with data hiding (unless you count memory management as data hiding ?) Guess what ? Whatever the language (Cobol, Java, Python, or even VB), chances are such an application would be written using a RDBMS (not even addressing the point about OS). There have been some major failure on such applications written with "serious" languages like Java. Know the sooo common "catch-all do-nothing exception handler" idiom in Java ? Man, you can't be serious ? Tell me this is a joke ? Most of what is actually labelled as "software engineering" is snake oil. They're trying to sell you silver bullets. Now where's the werewolf? Really nice metaphor. Alas, there are limits to what you can do with metaphores. (snip remaining) Nope. My position is quite clear : just don't do something *stupid*. For a definition of "stupid" that is indeed highly dependant on the context (which you snipped). s/encapsulation//g We were talking about language-enforced access restriction. Not about encapsulation. Not "anyone". Just those who do it where they obviously should not. And be sure that anyone cretin enough to mess with implementation *in the context mentioned by Russ* (context which, once again, you snipped) would find a "clever" way to do the same (or worse) in any language. You don't want such a smartass in your team, *specially* for critical stuff. You have a very strange way of handling context. My own experience is that firing an obvious cretin from a team leads to *less* work for the team - because then you don't have to re-read and rewrite all his code. This was *not* an error *in the context* this module was designed (and tested, QAd etc) for. Yes I was. Else I wouldn't have mention it. Because the problem had nothing to do with technology. Only with not being serious on specs / tests / QA. Hence my point : it's not because a module has been written using a technology (rightly) known for it's security and robustness that you can get by with non-technical issues. Do you think I am a newbie ? This is a different problem. Please don't mix bananas and screwdrivers. This is a beautiful dream. Reality is that either the guy is wise enough to not do something he know he shouldn't without due thinking and consideration, or he is dumb enough to do something he shouldn't one way or another. I do agree they shouldn't be builtins, but mostly because there are too few real use case for them to be builtins. (well, wrt/ exec, it's a statement to the problem is a bit different). It actually isn't, at least not without way too much overhead messing with call stack (and even then...). "Methods" need to freely access implementation attributes. But Python's "methods" are just wrappers around plain functions, which by themselves don't know (and shouldn't need to know) if they where defined within a class statement or not. Ok, let's pretend !-) No, I could live with it. Just a question now : how would this deal with functions defined outside the class statement but used as methods ? Oh, and please read until the end... s/encapsulation/data hiding/ InMyArms(tm) !-) And more overhead. Which is fine. Well, MHO at least. So technically, this means that you'd have an optionel check for _implementation attribute access outside methods ? Good news my friend, Pylint already do this (and quite a lot of other things too...). So wrt/ code reviews, QA etc, the "lack of access protection" is not such an issue, is it ? [URL]http://www.logilab.org/card/pylintfeatures[/URL] """ W0212: Access to a protected member %s of a client class Used when a protected member (i.e. class member with a name beginning with an underscore) is access outside the class or a descendant of the class where it's defined. """ [/QUOTE]

Verification