in reply to
Re^5: Why encapsulation matters
in thread Make everything an object?
I've read what he's written and his primary thrust is is that syntactic inconsistencies are unavoidable because anything more than a non-trivial use of the class requires them. Since he argues(1), that classes should be both complete and minimal -- needs that are sometimes in conflict -- he asserts that it's better to embrace that up front to accept the minimalism, other wise you have an explosion of methods which can make a class harder to maintain and wind up providing a bunch of useless features that people don't really need (his "nap" function was an excellent example).
Frankly, I agree with most of what he wrote, but avoiding the issues he describes without resorting to non-member, non-friend functions is often very easy -- but you don't want to hear it since, as you were quick to point out, he's an expert and I'm not. Thanks for making that distinction clear.
Update: I should also point out that what he's (the author BrowserUK points to) discussing involves a very long-standing issue with OO design that is extremely well-known, but it's only in the past few years that newer techniques for resolving it have been widely explored. The problem, basically, is that you can't have a class anticipate everything as this violates the need for minimalism and you're going to get it wrong anyway. The author presents one technique for resolving this issue, using something called 'non-member, non-friend functions'. There are, of course, quite a number of other ways to address this. I can think of at least six different techniques for resolving this issue. However, though the author correctly identifies a significant problem, stating that his is "the one true way" out of quite a number of different possibilities seems a bit limiting.
1: His "complete but minimal" argument is correct, in my opinion, and there are strong echoes of a famous paper which addresses this, but since I'm not an expert, I'm not entitled to an opinion here. Ironically, my concrete example is completely unrelated to the issues he pointed out, but somehow that appears to have been lost in the shuffle.