On Feb 13, 2006, at 7:08 PM, Adam P. Jenkins wrote:
> I wasn't aware of singleton *methods*.  I thought there were  
> singleton *classes*, in which case the C++/Java definition of  
> private would do just as well, since a particular object would be  
> the only instance of the singleton class. That is:

Well singleton methods are implemented by tucking them away in a  
singleton class
but you don't have to know about that implementation to utilize the  
facility:

a = [1,2,3,4]
b = [5,6,7,8]

def a.sum
   inject(0) { |s, x| s + x }
end

a.sum	# -> 10
b.sum	# NoMethodError exception


I think this all might come into play when you consider 'class  
methods'.  In Ruby, classes are
objects and so class methods are really singleton methods associated  
with a particular instance
of Class.   If you didn't have Ruby's concept of private then any  
class method could directly
call any other class method (because all classes are instances of  
Class).

You also mentioned concern about subclasses gaining access to  
implementation details of
a superclass.  I think Bertrand Meyer wrote about this in Object  
Oriented Software Construction.
If I remember correctly he explained that a subclass has a much more  
intimate relationship with
its superclasses than an external client has when using the same  
classes through their public API.
The benefits of this closer relationship is access to implementation  
details.  This is also the
greatest weakness since it increases the coupling between the two  
classes.  So it is a typical
engineering tradeoff between composition and inheritance as a way to  
reuse functionality.  If
you craft a class such that its implementation can not be reused via  
a subclass then it seems to me
you are making a pre-mature design decision about future classes and  
reuse.  Why cut off that approach
and why make the subclassed API as rigid as the external client API?



Gary Wright