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