On Fri, Mar 09, 2012 at 09:06:40PM -0800, Andrei Alexandrescu wrote: [...] > Insert obligatory link: http://drdobbs.com/184401197 > > Very insightful article. [...]
Wow. That's quite an interesting read, especially since it goes against conventional wisdom that non-member non-friend functions are "bad". But I see why this totally makes sense. Recently I looked up David Parnas' revolutionary paper about information hiding (the paper that started it all), from which it's very clear that the basic motivation behind encapsulation is resilience in the face of inevitable change. So the article linked above totally makes sense. Breaking changes tend to happen inside a class, so if something doesn't *need* access to private members, then it doesn't, and shouldn't, need to be a class member. In retrospect, I do find myself frequently factorizing code *within* a class such that most member functions don't actually need direct access to private members, or if they do, they use as few private members as possible to do what they need to do. So by Dr. Dobbs' standard, most of these member functions ought to be external to the class proper. This is where UFCS really shines... now I *can* actually move these members out of the class, and it doesn't even change the class API! Plus, *users* can add new pseudo-members and it extensibly enhances the class API while retaining that resilience to change. D is getting more awesome by the day. Now I truly can't convince myself to go back to C++! T -- There are two ways to write error-free programs; only the third one works.