I'm wondering about the fine structure of modules. There are 223 in my image after reorganize. Do we really want 223 module files on our disk and in the repository? I think it would be nice if we could break down the .sources more like at the major module level – about 24 now, probably more like 30-50, once we start taking advantage of this (Connectors, MathMorphs, Linda, PhotoSq, etc). A coarser organization would also make management of updates a bit simpler (I think), and the administrative overhead of supplying .seg versions. Also, moving classes within larger modules would not require moving source code.
Dan Ingalls
Right, times 3 or more... I've thought about treating the lowest levels of the module hierarchy as "light" modules already, by marking them as such. Keeping them together with their parent will make code a little more complex but the way it looks now it may be worth it.
> I think it would be nice if we could break down the .sources more
> like at the major module level – about 24 now, probably more like 30-50, once
> we start taking advantage of this (Connectors, MathMorphs, Linda, PhotoSq,
> etc). A coarser organization would also make management of updates a bit
> simpler (I think), and the administrative overhead of supplying .seg versions.
> Also, moving classes within larger modules would not require moving source
> code.
Agreed. I'll add something like a flag that signals whether a module should be put in different files than its parent, that will be sufficient. In fact this should go into the Repository object. I've used separate repository objects to support different R. implementations, but really it could be the hub of all file management too.
