Proposal: Package aliases

Yigal Chripun yigal100 at gmail.com
Thu May 15 13:40:13 PDT 2008


Robert Fraser wrote:
> Yigal Chripun wrote:
>> I like the general idea, but how many times do you need to import a
>> module like tango.io.Stdout in a file?
>> a related matter: why not separate the logical namespaces from the
>> actual file system organization? something like .net does with its
>> namespaces vs. assemblies?
> 
> I generally think that's a bad idea. It's more cognitive load on the
> programmer (worrying about what namespace something is in and the fact
> that a file can cover multiple namespaces). Looking up a particular
> piece of code is easy for both users and IDEs if there's a 1:1 name:file
> correspondence.

I'm not sure whether restricting the relation to 1:1 is good or bad.
this is a trade-in: you either get a more flexible mechanism albeit more
complex, or a simpler mechanism that's less flexible. I don't know
what's best for D in this regard.

however, there are other issues here:
for instance, eclipse allows you to define package names for folders
inside the project.
this is useful when your import is a.b.c.d.e.f.ThisIsMyClass;
the syntax allows you to just import/define this with one line, you
don't need to re-create the entire nesting in your code, like C++ needs
for namespaces. this however generates deeply nested folder hierarchies.
you can define a 1:1 relation between a module and a file, but also add
the ability to say to the compiler: the package named: a.b.c.d.e.f is
really just a folder called "f.src".
this way, you'd import derelict packages like:
derelict.openGL.*
derelict.openAL.*
derelict.SDL.*
etc..
and have each of the above packages point to that sub-project's src
directory.
an easy next step would be to define some sort of a manifest file that
contains metadata about the package, the same way Jar files/.net
assemblies are packaged. this allows you to have two different versions
of a package installed on the system without generating conflicts, or
define your folder hierarchy for sub packages to name two example use
cases. I'm sure there are more benefits to such packaging.



More information about the Digitalmars-d mailing list