gwtmp01 / mac.com wrote:
> 
> On Feb 13, 2006, at 3:23 PM, Adam P. Jenkins wrote:
> 
>> That said, I do think that Ruby's decision to make private mean  "only 
>> accessible to oneself" as opposed to "only accessible to  class 
>> members" is debatable.  In fact I don't see the point of it  from a 
>> practical point of view.  It seems to me that the main  reasons for 
>> making methods private is advertise that a) they're  implementation 
>> details that may change without notice in new  versions of the class, 
>> and b) they may require inside knowledge of  the class's workings to 
>> use correctly.  Both of these reasons would  be just as well served by 
>> allowing other instances of the same  class to access private members, 
>> so I don't see the point of the  extra restriction.  Anyone?
> 
> 
> Are you saying that the only visibility attributes should be public  vs. 
> protected
> as opposed to the current public/protected/private triumvirate?

No, I think the three levels of protection are all useful.  I was just 
suggesting that in this case, the Java/C++ definition of private makes 
more sense to me than the Ruby definition.  I was wondering if there was 
some reason I'm not thinking of why the Ruby definition makes more 
sense, at least for Ruby, or if it's just what Matz happened to think 
of.  Basically, to me the main reason for private methods is to protect 
implementation details of a class definition from being depended on by 
other code, so that I'm free to change these private parts of my class 
without breaking other code which depends on the non-private parts of my 
class.  So I don't see the point of drawing the protection boundary 
around *instances* of the class, rather than the code which implements 
the class.

> 
> One reason to support the distinction in Ruby is the existence of
> singleton methods.  It is possible for an instance to behave differently
> than any other instance of the class and as such you might want to
> support that different behavior by marking some methods as private.

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:

a = "Hello"

class <<a
   private
   def superSecret
     "foo"
   end

   public
   def to_s
     superSecret + self
   end
end

In this case, the superSecret method is private to the "a" object, 
whether private follows the C++/Java definition, or the Ruby definition. 
  The Java definition of private would say that any instance of a.class 
can call the superSecret method from one of its methods.  However, since 
"a" is the only instance of a.class, this amounts to the same thing as 
the Ruby definition.

If it is possible to add singleton methods to instances of an existing 
class, then I can see why it might make sense to make said singleton 
methods private to that object.

Adam