From: Paul Prescod <paulp@...>
Date: 2002-09-06T01:42:05+09:00
Subject: Re: Ruby aesthetics

On Thu, 5 Sep 2002, William Djaja Tjokroaminata wrote:

> Hi,
>
> I agree that "@" and "self." are very minor syntactic choice.  Even when
> the object itself is passed as the first argument into an object method I
> have no big problem with that.  The biggest problem for me is that in
> Python an object is pretty much like a hash; this is equivalent as having
> all data members as public in C++. (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.)

I can understand why this would bother some people. It does violate OO
purity as it is typically described by its promoters. But there are a few
points to keep in mind:

 * In C++ you can always (?) get at supposedly private and protected
members using pointer arithmetic. In Ruby and Java you can also almost
always subvert the privacy using introspective techniques. In Ruby and
Python especially, we should not confuse a mechanism for making peeking
*difficult* with a security mechanism that makes it *impossible*.

Stroustrop says: "The protection of private data relies on
restriction of the use of the class member names. It can therefore be
circumvented by addressing manipulation and explicit type conversion.
But this, of course, is cheating. C++ protects against accident rather
than deliberate circumvention (fraud)."

 * In Python, you can make a member private in one of two ways. One you
might call advisory, the second quasi-language enforced. The advisory way
is just to put an underscore in front of the member name. This indicates
that it is special and should not be fiddled with unless the fiddler
knows what to do. The quasi-language enforced way is described here:

 http://diveinto.python.ru/fileinfo_private.html

In a sense, this is an advisory too, but it has first-class language
syntax and it takes very deliberate effort to work around.

 * Neither mechanism is 100% language enforced but neither is Ruby or C++
or Java "privacy" 100% language enforced. In Java you can probably enlist
the help of the security manager to make it 100% enforced and in Python
you could try to use the Bastion module but these are big sticks that are
not appropriate for most day-to-day programming. Perhaps Ruby has an
equivalent way to disable introspection. Plus you have to be careful how
strongly you trust these things. There are known security holes in Bastion
and there have been holes in Java before.

 * Python did have an access keyword around Python 1.2. I can't remember
the exact details of why it failed as an experiment but I imagine that the
conversation might have gone something like the above. Perfect privacy is
not practically attainable, nor desirable and advisory privacy is
therefore good enough. Arguably there is no need for a first-class
language feature to deal with it *at all*.

> In Ruby, on the other hand, all data members are
> private by default (which is the recommended practice in C++), unless we
> explicitly make it otherwise (through the accessor methods).

I don't personally take C++ as a guide for software engineering practice.
IMHO, in a scripting language, subverting the rules should be easy because
the most important thing is getting your job done and sometimes that
requires rule-subversion. As long as rule-subversion is *conscious* and
not accidental, grown-ups can decide when software engineering concerns
outweigh expediency (and performance!) issues and vice versa. A simple
leading "_" can only be subverted consciously. Subverting Python's name
mangling requires even more effort. Subverting Ruby's privacy takes even
more effort still. I don't think it makes as big a difference where you
are on this spectrum as you do.

>   Therefore we
> have a standard information hiding in Ruby and not at all in Python.  This
> is one of the most important reasons why I switched from Python to Ruby.

That's simply not true. Python has an explicit information hiding feature
described above. You may or may not like it aesthetically as is your
right. You may also think it is too far in one or the other direction in
the safety/convenience spectrum. But you can't say it doesn't exist!

 Paul Prescod