private access modifier in ruby

Tags:

Dňa Streda 15 Február 2006 01:58 Minkoo Seo napísal:

> 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

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *