I think this case might be realistic.  I have a class (such as a TCP
stack), and it has thousands of instance variables, both from itself and
from its parent and great grandparents.

Some user decides to inherit from my TCP class, such as to modify from TCP
Reno to TCP with SACK.  In the derived class, the user inadvertantly
creates an instance variable with a name that already exists in the
original TCP class.  (Because instance variable creation is dynamic, even
if the user invokes "aTcp.instance_variables", he may not see all the
complete instance variables.)  Voila!  Suddenly my TCP class stop working
properly.

By having private variables, even with the same name, my TCP class and my
user class will access different data.

Regards,

Bill

P.S. Because of this potential problem, usually I initialize all my
instance variables to something, even to nil, in the
initialize() method.  But this is more from the programmer's
own discipline, and not by the help from the language itself.
===========================================================================
MikkelFJ <mikkelfj-anti-spam / bigfoot.com> wrote:
> I'm not arguing for or a against private variables. They may be a good tool
> for documenting intention. But without knowing the details I can't see
> private variables would add any real safety. Ruby already has a fair level
> of data hiding by not allowing direct access to member variables. My point
> was that you can always abuse a system and safety comes from adhering to
> conventions not by enforcing them.

> Mikkel