On packages and naming them

[Yigal Chripun]

terranium wrote:
> Bill Baxter Wrote:
> 
>> [Strategy 1] Just use a generic name like "utils" or "tools".  This 
>> makes the D compiler happy, but only until someone else decides to name 
>> their package the same thing.
>>
> One more option:
> import projectname.all;

I'll also add something I read in this NG in the past about python's
package system:
you can define a file called __this__.py with imports. this is a
reserved python symbol so you cannot import it directly. the idea is
that you can write
import package.subpackage; //replace with the python syntax for this
and since you asked for a package and not a module, the compiler will
rewrite it to mean:
import package.subpackage.__this__;

in the D version this would mean to define a special this.d file for
packages.

also, in the exciting D system it can be done in tango as well due to
the naming convention:
tango packages are all lowercase, while modules are CamelCase. this mean
you can use the following:
import package.subpackage.Module;
import package.Subpackage;

this works because d is case sensitive. so even if you try this on
windows (where FSs are case insensitive) it will work cause the compiler
will recognize them as different symbols, and will know to look for the
right file in the file system.

at least, this is what I read in the NG.

I prefer something in this line more than .all since .all implies the D
equivalent of import stuff.*; in Java.
the two approaches above can be used when you want to import some sort
of Public API (user defined) instead of all the symbols (including the
internal ones)