On 3/5/12 12:03 AM, Gershom Bazerman wrote:
So, suppose we have a locally declared fields solution (such as DORF). Now, where do these fields live? Arguably, we want a module per record.
Rather, part of the point of all this is precisely that we *don't* want one module per record. That's the organization required presently, since it's the only way to use the module system for namespace resolution. Ideally we should be able to define multiple records with the same field name within a single module, rather than being forced to break the module up into many files (and polluting the module namespace along the way). Also, if your goal is to have a global namespace, that can be approximated precisely by placing all declarations in a single module. In virtue of being in a single module, they're all in the same namespace; the client then just has to import your "global" module in order to get everything. Indeed this has the benefit of modularity because if my code depends on two separate projects which both want "global" namespaces, this would allow me to use them simultaneously. If we are to have any packaging and code reuse at all, this ability to compose multiple packages is absolutely essential. Furthermore, this would *avoid* spurious recompilation, since if I upgrade my dependency on project A then I don't need to recompile any modules which only depend on project B. -- Live well, ~wren