----- Original Message -----
From: "Joel VanderWerf" <vjoel / PATH.Berkeley.EDU>


> Matt Gushee wrote:
> > On Fri, Sep 06, 2002 at 12:33:23AM +0900, Gavin Sinclair wrote:
> >
> >>>(Sure, there is a way around this in
> >>>Python, but it has to be manually made by the programmer, not built-in in
> >>>the language itself.)
> >>
> >>AFAIK, you can't make data private in Python.
> >
> >
> > No, you can't. You can prevent a module or class from *exporting* a name
> > by prefixing it with a single underscore ... but anyone who knows that
> > name exists can still use it in qualified form. You can take this one
> > step further by prepending __  (double underscore) to an instance
> > method name, and the byte-compiler will generate an obfuscated name,
> > providing pseudo-privacy ... but it does so in a predictable fashion, so
> > it is still possible to access the method if you really want to.
> >
> > These were deliberate design choices. The philosophy behind it is that
> > an API should be a guide for developers, not a straitjacket.
> >
>
> Even ruby doesn't make ivars completely private:
>
>    obj.instance_eval {@x = 1}
>
> And you can always add your own methods to any class and manipulate
> internal state as you wish.
>
> But in each case, you have to type something that looks quite different
> from ordinary ivar access. This explicitness feels (to me anyway) like
> an extra layer of safety.

Certainly.  That instance_eval method is far removed from normal programming
practices.  Adding methods to classes is something that we generally celebrate,
too - although it's certainly weird to start with, depending on your
background.

Some friends of mine think it's too strange and unsafe to modify classes after
they've been built, and I don't blame them (I don't agree, but I don't blame
them).  These things take time to appreciate...

At least Ruby suffers from good design, not hacks.

Gavin