Da Streda 15 Februr 2006 01:58 Minkoo Seo napsal:
> David Vallner wrote:
> > Dna Utorok 14 Február 2006 01:08 Adam P. Jenkins napísal:
> > > 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.
> >
> > And I don't see the point of drawing a restriction in Java's private /
> > protected smack-dab across an inheritance hierarchy. I accuse the whole
> > thread of having degenerated into pure religion.
>
> Private/protected meaning of Ruby is unique, and I believe some kind of
> elaboration on that point is needed. What method is accessible from the
> outer space is quite important in learning a language, isn't it?
>
> Let me put this way. On one hand, ruby allows me to redefine or add
> methods to a class which I've not defined. Also, it is possible to
> redefine or add methods to a instance of class. Subclasses can access
> parent classes. Moreover, there's no notion of 'final(Java)/sealed(C#)'
> class in ruby. From this point of view, ruby's objects are quite
> dynamic because they can be changed anytime. If these are the only
> characteristics in ruby, I would just happy with it.
>
> However, on the other hand, ruby does not allow an instance to access
> other instance even if they are the instance of the same class. In this
> case, an object is something that can not be easily accessed.
>
> I feel that these two conflict, and need justification.
>

I don't see the concept of method access restrictions as anything 
standardized. If I have my facts correctly, CLOS didn't have anything 
similar, neither did Smalltalk, nor Perl's or Python's object systems (until 
recently for the latter). The C++ line of languages seems to be consistent in 
this, and brief googling indicates this was the same in Simula.

Considering Ruby seems to me far, far closer to the first group of languages 
than the second, I'd just take the access restriction capabilities more as a 
perk than a core feature. Separating public API from the internals, which you 
can do, is more important in my opinion than pettifoggery about how to 
separate internals from other internals.

Rule of thumb: use protected for internal interfaces, private for helper 
methods for an algorithm. The first gives you all the flexibility you need 
without directly exposing your internals to clients, the latter lets you 
split code into bitesize chunks without risking state inconsistency by 
accidentally calling strange helper methods from unexpected places.

I want example code where it's necessary for other instances of the same class 
to access a method while unthinkable of an instance of a subclass to do so 
before I consider this as more than "Why isn't Ruby like My Favourite 
Language?" whining.

David Vallner