Le 18 nov. 08 à 13:15, David Teller a écrit :

> But, to keep things ordered, we will still need modules
> [Threads.Threads], [Threads.Mutex], [Threads.RMutex]...
> [CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a  
> hierarchy
> already.

If you include in batteries an external package that has its own  
hierarchy and is designed to be opened I don't mind having that  
hierarchy. In that case you can just add the new toplevel entry  
CoThread. And if I want to use CoThread, I just open CoThreads, not  
Control.Concurrency.CoThreads. Just try to keep it as flat as  
possible, don't try to force modules in an ad-hoc hierarchical  
taxonomy to try to sort out modules. I don't care if the toplevel list  
of modules is three hundred pages long if there is an efficient mean  
to access their documentation (like tags). I do however care a lot if  
it becomes bureaucratic to be able to _use_ a module in my code.


Le 18 nov. 08 à 13:22, Richard Jones a écrit :

> Easy - look at CPAN[1].  If you want to scale a project you have to  
> make decisions that allow a distributed network of people to  
> cooperate, without needing too much central coordination.

But (unfortunately, sorry to repeat that) Batteries is not a CPAN like  
initiative. It aims at giving a library of modules/syntax extensions  
selected by the library maintainers, as such it is inherently  
centralized and I don't think that questions (1) or (2) are actually  
pertinent for the project.

Best,

Daniel