John M. Dlugosz wrote:
A method can refer to private attributes etc. in other objects than
self. This is unlike Smalltalk and like C++. Which objects?
Obviously, those that _have_ them in the first place. Does the variable
used as the invocant, or return value if it is an expression, have to be
statically typed as being of the identical class? Or does it apply that
constraint implicitly at run-time? If the former, note that in C++ it
must be the identical class, NOT a derived class, even though that is
simple to work around, because that is a conceptual point.
A method is defined within a role or class, as is an attribute. A private
attribute can generally be referenced only by a method declared in the same
role or class as said attribute.
A method can reference its own role's/class's private attributes for any
objects of that role/class, regardless of whether said object is the
current method call's invocant or not.
If a role or class is composed into another class or is subclassed, the
(for example) subclass can not reference the private attributes of its
parent class.
As an exception to the above, if a particular class says that it "trusts" a
particular other class (using "trusts Otherclass;" as a trait), then the
trusted class can also reference the privates of the first class.
So "trusts" is useful when you have a good reason for certain classes to
see each other's internals but that they are otherwise private; for
example, say you're implementing a graph, and you have a separate class to
define a graph node and the whole graph; those 2 classes are conceptually
one feature, but are 2 classes because they provide 2 separable interfaces
to users; the "trusts" lets you do the right thing interface-wise while
remaining secure without contortions.
Everything I just said ignores the fact that you can always additionally
make public accessor methods for private attributes, to control/protect
limited access to them for the general public.
-- Darren Duncan
