Why I Want Global Field Names (By Default)

[wren ng thornton]

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