On Sat, 10 Mar 2012 00:06:40 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Insert obligatory link: http://drdobbs.com/184401197
Very insightful article.
Interesting point to make about D, however. It's really *difficult* to
make related non-member non-friend functions, since all functions inside
the same module as a type are friends. In order to follow the
recommendations, D non-member non-friend functions must go in another
*module*.
I don't necessarily agree with the argument, because it's a
fully-objective view of something that is very subjective.
For instance:
class A
{
private int a;
}
class B
{
private int b;
}
void nonMemberBFunction(B b)
{
b.b = 5;
}
Not only is nonMemberBFunction potentially dependent on B's
implementation, but it's also potentially dependent (by Scott's rules) on
A's implementation. Therefore, A has less encapsulation.
But any sane person can see that nonMemberBFunction does not access A.
Since everything to be examined/updated when updating A's implementation
is in the same file (and that implementation is readily available), I
think you should not count non-member functions that don't *access* the
class in question against the encapsulation factor. Yes, this makes
things more reliant on convention (i.e. denote in documentation somehow
what functions access private data), but since you can't turn friends off
without extreme practices, I don't think you have any other sane choices.
In D, interestingly, making things member functions is not any different
than making them non-members, it seems. In fact, I'd argue it's *more*
appropriate in D to make things member functions, since it serves as
implicit documentation that it likely accesses only the class members. I
wonder what Scott would say about that?
-Steve
