<br><br><div class="gmail_quote">On Sat, May 24, 2008 at 10:14 AM, Fuzzyman <<a href="mailto:fuzzyman@gmail.com">fuzzyman@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On May 24, 2:58 pm, Ben Finney <<a href="mailto:bignose%2Bhates-s...@benfinney.id.au">bignose+hates-s...@benfinney.id.au</a>><br>
wrote:<br>
<div class="Ih2E3d">> Sh4wn <<a href="mailto:luckyluk...@gmail.com">luckyluk...@gmail.com</a>> writes:<br>
> > first, python is one of my fav languages, and i'll definitely keep<br>
> > developing with it. But, there's 1 one thing what I -really- miss:<br>
> > data hiding. I know member vars are private when you prefix them with<br>
> > 2 underscores, but I hate prefixing my vars, I'd rather add a keyword<br>
> > before it.<br>
><br>
> From whom are you trying to hide your attributes?<br>
<br>
</div>Actually, 'data hiding', although vastly overused by the static crowd<br>
can be a reasonable thing to want.<br>
<br>
For example, at Resolver Systems we expose the spreadsheet object<br>
model to our users. It hasa public, documented, API - plus a host of<br>
undocumented internally used methods.<br>
<br>
We would really *much* rather hide these, because anything our<br>
customers start using (whether documented or not) we will probably<br>
have to continue supporting and maintaining.<br>
<br>
The 'we told you not to use that' approach, when applied to paying<br>
customers doesn't really work... all they see is that you broke their<br>
spreadsheet code by changing your API.<br></blockquote><div><br></div><div>It apparently works for Sun Microsystems. They do that with a whole bunch of packages in Java, and Java does allow data hiding.</div><div><br></div>
<div><span class="Apple-style-span" style="font-family: 'Lucida Grande'; font-size: 12px; white-space: pre; "><a href="http://java.sun.com/products/jdk/faq/faq-sun-packages.html">http://java.sun.com/products/jdk/faq/faq-sun-packages.html</a></span></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
You can make members truly private by proxying, but it is a bit<br>
ungainly.<br>
<br>
Michael Foord<br>
<a href="http://www.ironpythoninaction.com/" target="_blank">http://www.ironpythoninaction.com/</a><br>
<div><div></div><div class="Wj3C7c"><br>
<br>
><br>
> In Python, the philosophy "we're all consenting adults here" applies.<br>
> You shouldn't pretend to know, at the time you write it, all the uses<br>
> to which your code will be put. Barriers such as enforced "private"<br>
> attributes will only cause resentment when people, despite your<br>
> anticipations, *need* to access them and are then forced to hack their<br>
> way around them.<br>
><br>
> If you want the users of your code to know that an attribute should<br>
> not be used as a public API for the code, use the convention of naming<br>
> the attribute with a single leading underscore. This is a string<br>
> signal that the attribute is part of the implementation, not the<br>
> interface. The reader is then on notice that they should not rely on<br>
> that attribute; but they are not *prohibited* from using it if<br>
> necessary to their ends.<br>
><br>
> > Python advertises himself as a full OOP language, but why does it<br>
> > miss one of the basic principles of OOP?<br>
><br>
> Who taught you that enforced restrictions on attribute access was a<br>
> "basic principle" of OO?<br>
><br>
> Perhaps you're confusing the "encapsulation" and "abstraction"<br>
> principles for enforced access restrictions; they're not.<br>
><br>
> > Will it ever be added to python?<br>
><br>
> I hope not.<br>
><br>
> --<br>
> \ "Why was I with her? She reminds me of you. In fact, she |<br>
> `\ reminds me more of you than you do!" -- Groucho Marx |<br>
> _o__) |<br>
> Ben Finney<br>
<br>
--<br>
<a href="http://mail.python.org/mailman/listinfo/python-list" target="_blank">http://mail.python.org/mailman/listinfo/python-list</a><br>
</div></div></blockquote></div><br>