Proposal: Package aliases

[Yigal Chripun]

Bill Baxter wrote:
> Yigal Chripun wrote:
>> Bill Baxter wrote:
>>> Bill Baxter wrote:
>>>> Using packages for modules in D is good.  It prevents name clashes.
>>>> But you need a unique package name.  The more unique (i.e. longer),
>>>> the more a pain it becomes to use a bunch of modules from that package.
>>>>
>>>> For example in Java, all of SWT is in the org.eclipse.swt package.
>>>> For DWT Frank just shortened the package to "dwt" because having to
>>>> type something longer so many times would be a pain (and I guess
>>>> because dwt isn't really an Eclipse project.)
>>>>
>>>> Anyway, putting code inside uniquely named packages is a good thing.
>>>> But nobody wants package names to be very long, because you have to
>>>> type them every time you do an import.  Hence we have "std", and
>>>> "tango". The longest "vendor" package name I know of is "derelict".
>>>> And quite a bit of D code out there uses no package at all.
>>>>
>>>> I think it would be convenient if packages could be aliased.
>>>>
>>>> Right now this is not possible:
>>>>
>>>>   alias tango.io tio; // this alias actually compiles, but...
>>>>   import tio.Stdout;  // import using it doesn't work
>>>>
>>>> (Note for the Tango non-savvy: import tango.io.Stdout *is* valid.)
>>>>
>>>> So my proposal is simply to make the above code work.
>>>> I was actually mildly surprised that it didn't.
>>>>
>>>> If we had this then people would be more free to name their packages
>>>> whatever they like, comfortable in the knowledge that users will only
>>>> have to type the full package name once.
>>> Another possibility would be a new form of "with" for packages:
>>>
>>> with(dwt.widgets) {
>>>   import Button,Control,Display,Shell;
>>> }
>>>
>>> --bb
>>
>> I like the general idea, but how many times do you need to import a
>> module like tango.io.Stdout in a file?
> 
> I was just trying to use something a lot of people would recognize.  A
> better example would be dwt:
> 
> import dwt.DWT;
> 
> import dwt.dwthelper.Runnable;
> 
> import dwt.widgets.Display;
> import dwt.widgets.Shell;
> import dwt.widgets.CoolBar;
> import dwt.widgets.CoolItem;
> import dwt.widgets.ToolBar;
> import dwt.widgets.ToolItem;
> 
> import dwt.events.ControlEvent;
> import dwt.events.ControlAdapter;
> 
> import dwt.layout.FillLayout;
> import dwt.layout.FormLayout;
> import dwt.layout.FormData;
> import dwt.layout.FormAttachment;
> import dwt.layout.GridLayout;
> import dwt.layout.GridData;
> 
> import dwt.graphics.Rectangle;
> 
> import dwt.opengl.GLCanvas;
> import dwt.opengl.GLData;
> 
> 
> It would be nice if the redundancy could be reduced somehow.
> 
> 
>> a related matter: why not separate the logical namespaces from the
>> actual file system organization? something like .net does with its
>> namespaces vs. assemblies?
> 
> Can you explain what .NET does a little more?  I'm not familiar with it.
> 
> --bb

.net uses assemblies. ON MSDN they like to refer to them as "logical
dlls" they are closer to Java's Jar files more than DLLs, I think.
such an assembly contains all the code to be run (I think in MSIL
format) together with a manifest file with metadata, like versions,
namespace mappings and such ( I don't know what it contains exactly, but
it would be easy to find out).
the idea is that you use namespaces in your C# code, as logical code
units. when compiling you give the compiler the assemblies and it uses
the metadata inside to map assemblies to namespaces.
also, an assembly can contain compiled code from different languages due
to the nature of .net.
that's just some info I've found via google. Someone more knowledgeable
in this could provide more details. something similar to this scheme can
be added to D's DDL, or something similar.
Java uses Jar files to package their libs/executables and .net uses
those assemblies. D still uses dlls which we all know their problems.
maybe even adopting such a scheme could be used to make D packages
portable. maybe via providing a version for each OS (similar to mac OSX
fat binaries) and allowing the compiler to chose the correct version, or
using some portable format, though this would be optional if at all
available, since we all use D cause it's a natively compiled language :)

for that to work We just need to find a scheme that allows portability
without affecting performance. I'm sure it is possible without creating
our own 500MB (I don't know the exact size) runtime like .net has or a
VM somilar to Java's.