On Tue, Jul 28, 2009 at 4:42 PM, Stewart Gordon<smjg_1...@yahoo.com> wrote: > Sergey Gromov wrote: >> >> Mon, 27 Jul 2009 07:59:40 -0500, Andrei Alexandrescu wrote: >> >>>> Is it appropriate to define multiple classes, structs, templates, etc >>>> within a single module? What considerations should inform the decision >>>> regarding the placement of module boundaries? >>> >>> I think it's appropriate because many pieces of functionality come as a >>> bundle. The rule of thumb is, module provides the functionality, and it's up >>> to the designer to decide what that entails. >> >> That's the problem. On one hand, it's desirable to see a module as a >> functionality bundle. On the other hand, module is the smallest >> available unit of encapsulation. That is, if you have a class and >> change its private implementation, this may affect *anything* in the >> same module. Hence Tango's hundreds of modules in dozens of packages, I >> think. > > I guess that's meant to encourage you to keep your modules small enough that > you know what you're doing. > > At the smallest level, it would be a matter of: If in C++ you would declare > Qwert to be a friend of Yuiop, then in D you put Qwert and Yuiop in the same > module. You could implement the converse as well, but for a bunch of small > classes it usually isn't worth it. > >> It also adds to the problem that most people familiar with OO paradigm >> consider classes to be such encapsulation units. Surprizes are >> inevitable. > > I once came up with the idea a 'veryprivate' protection attribute that would > do this, but I can't seem to find the post now.
"super private" :-) Sorry I just can't let that old idea to call immutable "super const" die. It was just too darn cute. --bb
