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