From: Marc Merlin <mmerlin@...>
Date: 2004-12-30T15:51:44+09:00
Subject: Re: #send and private methods

I agree with Glenn Parker that denying access to private methods will
unquestionably prevent programmers from accomplishing tasks that they
otherwise could, and I agree that Ruby programmers for the most part are
aware that they are breaking the rules by bypassing information hiding. 
(The same could be said of denying access to object attributes, as well.)
I also agree that the creator of an implementation cannot anticipate all its
possible future uses.

By designating a method as a private the implementor is saying that its
appearance in the code is in some way incidental.  To some extent that is
his or her call to make, although admittedly it may be wrong.  I'm not
saying that this is the implementor's right in any proprietary way, I'm
saying that as a matter of fact the implementor has decided that some
behavior for the component that will be exhibited publically - the type, so
to speak - and the rest of its functioning will be hidden.

The motivation for hiding this functioning is actually an admission not of
omniscience but of uncertainty on the part of the implementor - uncertainty
whether the private methods will be retained in future versions of the
component or whether they will function identically if they are retained. 
The same is true with any successor implementors who strive to preserve the
type of the software component.

Now I think it's all well and good if a Ruby programmer aware of the risks
undertakes to violate access restrictions in order to accomplish an
otherwise impossible (or exceedingly difficult) task.  The rules of
informed consent would seem to apply and the chips would seemingly fall
where they may.

The problem occurs when the aware access-control dodger in turn creates an
software artifact used by other people.  They themselves are unaware of the
fragility that has been introduced into software system upon which they are
relying.  A "private" change in a component invisible to them - a change
not affecting the proper functioning of that component in the least - could
blow them out of the water.

[Perhaps this problem could be addressed by introducing another dimension of
"tainting" to indicate other forms of software risk.  That's a topic for
another thread.]

In summary, implementors publish types.  They and their successors retain
the perogative to change their implementations consistent with such types,
otherwise they have simply introduced a new type.  The people placed at
risk by the subversion of the "type boundary" are not necessarily the
first-order clients of the software component, but others, maybe several
layers removed, who incorporate the subverting components into their
software creations.

I should be clear.  Object#send isn't a big deal for me.  Someone raised an
issue and I wanted to share my concerns.  I have the utmost respect for the
Ruby community and am sympathetic to points on both sides of this question.

Cheers,
Marc Merlin