On Tue, Apr 12, 2005 at 02:57:48PM -0400, S. Alexander Jacobson wrote:
> My main goal here is to free the user from the hassle of manual package
> installation. A module written in one location should "just work" when
> moved to another. Right now, we have that location transparency within a
> single box or networked file system. I am saying we should also have it
> for moves accross the Internet.
>> So, the meaning of an import statements should not depend on its context
> (in effect, module identifiers in import statements should be a form of
> URL) and compilers/interpreters should be able to resolve those URLs to
> module implementations without user intervention.
>> And, if the meaning of module names is parametrized by package then
> package names should be part of import statements. If packages are
> purely adminisistrative, then they shouldn't.
>> Do we agree on at least this much?
What you describe sounds to me like a nightmare. It means I'd have to have
a different import statement (protected by #ifdefs) for every version of
each module I want to support--since in practice every version will change
the interface.
If all users are always connected to the internet, and all packages work
with every version of every compiler, then yes, having a global namespace
for modules where every interface change results in a module name change
sounds great. But in a world where some users use older compilers, and
some users aren't always connected to the internet, one would like to be
able to change module interfaces without having to change all code that
uses that module.
--
David Roundy