Hi Wolfgang. Thanks for your response. I agree in many cases derived classes just extend an existing class, and all objects of the parent class are relevent to the children. In fact, I have often written quite a base class quite defensively in C#, only to find that I do indeed need to expose further properties to the derived ones later. However, sometimes it is good to keep stuff in the base class private. What if there was an algorithm in the base class which depended on a class level instance variable to govern its behaviour? In ruby, all derived classes would be allowed to change this variable, possibly breaking or affecting it's operation (especially if the derived class was written by a different developer). In rails, you can set instance variables in the ApplicationController, and they're automatically available in other controllers. The behaviour of ruby I described means that in the other controllers you've got to be careful not to accidentally overwrite this value. i.e. We have not explicitly exposed the instance variable in the base class but in the derived classes we still need to know about the implementation of the base class. This kind of breaks the orthogonality of the design, doesn't it? Rich. Wolfgang Nádasi-donner wrote: > Richard Roberts schrieb: >> > Instance variables are part of an object, they are the attributes that > contain > values special for each instance. > > From an OO point of view a derived class can only extend an excisting > class. > This means all objects of the parent class are still relevant for the > child, > plus additional ones. > > So it doesn't make any sense to hide these instance variables. > > For local working inside a method "local variables" are available. > > btw - There is one method in Ruby which I sometimes use for special > cases, and > which breakes the rule, that a derived class should only extend a class, > an not > shorten it's capabilities: "Module#undef_method". > > Wolfgang Nádasi-Donner -- Posted via http://www.ruby-forum.com/.