My own take on 'trusts' is that I consider its main purpose is to let
programmers *avoid* contrivances when they want to define something that would
otherwise be a single class but is split into multiple classes for better
elegance. For example, say you want to define a graph of some kind, and for
elegance you have a separate container and node and side classes, even though
conceptually these are all integrated parts of a whole. Say in this case your
container class has a list of all its child nodes and each node has a pointer to
its container. Often you'd want to invoke a method which would then ensure that
pointers in both classes are updated but you don't want it to be possible for
users to just update one or the other but not both. Sounds like private, but
'trusts' makes it work well. Suffice it to say I consider 'trusts' to be very
important but best used for limited cases like what I mentioned. -- Darren Duncan
Sean Hunt wrote:
On 03/26/2010 04:16 PM, Jason Switzer wrote:
Also, this discussion of "trusts" piqued my interest; this sounds like
a bad
idea. Those of you who have worked extensively with C++ should bemoan
"trusts" as much as friend classes. They break encapsulation for special
cases, almost encouraging truly hideous object models that ultimately
become
purely public (painful on a large scale). I can't stress enough that if
these are of similar nature, "trusts" should be removed. I'm all ears
though
if someone knows of a reason why they're more useful than onerous.
-Jason "s1n" Switzer
Here's the C++ FAQ Lite's answer to that:
http://www.parashift.com/c++-faq-lite/friends.html#faq-14.2
I'm not necessarily sure that this applies to Perl 6 too much (I really
haven't paid a ton of attention to access control), but I've always
considered C++'s friends to be roughly equivalent to Java's
package-private in terms of where they fit into one's notion of
encapsulation - this is not to say that they are the same thing!
Sean Hunt
