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

Reply via email to