Arbitrary abbreviations in phobos considered ridiculous

[Steven Schveighoffer]

On Sat, 10 Mar 2012 00:06:40 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at 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