Developing a plan for D2.0: Getting everything on the table

Stewart Gordon smjg_1998 at yahoo.com
Tue Jul 28 16:42:31 PDT 2009


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.

Stewart.



More information about the Digitalmars-d mailing list