* thmpsn....@gmail.com (Mon, 2 Feb 2009 09:02:13 -0800 (PST)) > On Feb 2, 2:55 am, Stephen Hansen <apt.shan...@gmail.com> wrote: > > > This is proven > > > by your statement above, whereby you are driving a user away, > > > simply because the language, in one small aspect, does not > > > give him what he wants, and the tenor of this thread has been > > > very much: "That's how it is - like it or lump it", and no amount > > > of careful explanation of why people want the feature has cut > > > any ice - > > > > I'm missing the careful explanation. What I've heard is that the lack > > of enforced encapsulation is "a danger". What I've heard is that > > people want it because they've been told they should want it and > > believe that. Why? > > Who has said the latter? Are you just trying to spread FUD?
No, he's not. He's giving his and other people's impression of the pro- private group's arguments. They construct cases that do not exist in reality or can more-than-easily be avoided. > > There have been no "careful explanations" to answer that, in my mind. > > And thus my response is: the practical possibility of needing access > > vastly outweights the theoretical situation that might go bad if > > encapsulation wasn't there. Why? Because in any real situation, IMHO, > > *forced* encapsulation is pointless. > > I think you've gotten too subjective on this matter. You might as well > say that we don't need no stinkin' OOP, we could all just be > programming with goto's. It's even simpler: "don't use other people's underscores". It couldn't get more simple than that. > > > It has all the time been countered with statements > > > about how the proponents of private attributes "don't need it", > > > (as if they are plain dumb), > > > > They don't need it. No one has shown a *real* reason why. The only > > reasons provided are "its a DANGER" that someone "MIGHT DO BAD". > > That's not a real reason. If its your project that someone is doing > > bad in, this is a situation which can be *clearly* specified in a > > projects policy and coding standards and can be *trivially* tested for > > with simple static analysis in nearly all cases. The problem is the > > person and not the code then. There's *countless* other ways that > > person can do bad if you're allowing them to commit blindly anything > > into your project. > > Aha! I see this attitude quite often among C/C++ people, regarding > buffer overflows and uninitialized pointer dereferences: someone will > say "C and C++ are unsafe languages because they allow you to overrun > buffers", then a C/C++ zealot will respond "Hire some good > programmers". > > SAME ATTITUDE. Not at all. Buffer overflows cannot be easily avoided in C/C++ like languages. On the contrary you can easily avoid other people's privates by simply not using their underscores. It's really that simple. Even I got that - and I'm a really simple guy. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
