View mode: basic / threaded / horizontal-split · Log in · Help
May 14, 2008
Proposal: Package aliases
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.

--bb
May 14, 2008
Re: Proposal: Package aliases
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
May 14, 2008
Re: Proposal: Package aliases
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?
a related matter: why not separate the logical namespaces from the
actual file system organization? something like .net does with its
namespaces vs. assemblies?
May 14, 2008
Re: Proposal: Package aliases
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
May 15, 2008
Re: Proposal: Package aliases
On Thu, 15 May 2008 02:06:44 +0300, Yigal Chripun wrote:

> a related matter: why not separate the logical namespaces from the
> actual file system organization? something like .net does with its
> namespaces vs. assemblies?

It would be useful to separate the file system assumptions from the
package/module name, but there would still have to be some mechanism for
the compiler to map package/module names to the file system. It has to read
those files at compile time so it has to know where to get a module's file
from. The current mechanism works but it enforces a number of restrictions
on us. 

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
15/05/2008 12:09:15 PM
May 15, 2008
Re: Proposal: Package aliases
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.
May 15, 2008
Re: Proposal: Package aliases
Bill Baxter wrote:
> I think it would be convenient if packages could be aliased.

I'm really amazed that this is a problem. For example in Java, I almost 
never need to worry about the name of a package or if the package name 
is long, or how many characters I'll have to write in the import. Why? 
Simply because I use an IDE that does that for me. So instead of 
worrying about structuring a source file just to get the imports right, 
aliasing imports and making things shorter, I just need to worry about 
the problem I need to solve, algorithms, etc.

If you have only one way to import a module, than it becomes simple: you 
don't have to think how you'll import import it, you just do it.

I also find useless and confusing to alias imported symbols like "import 
foo : bar = baz"... who actually uses that? What for?

Just some thoughts...

(I'm sorry I always mention an IDE and stuff like that, but the point 
is, I can focus on the problem instead of on the structure of the source 
file)
May 15, 2008
Re: Proposal: Package aliases
"Ary Borenszweig" wrote
> I also find useless and confusing to alias imported symbols like "import 
> foo : bar = baz"... who actually uses that? What for?

The main reason is if you have two different modules that contain the same 
symbol names.

The main place I use it is for tango.text.convert.*  the Integer and Float 
modules both have toString functions defined.  If you import both, you need 
to fully qualify the name, however, if you do:

import Int = tango.text.convert.Integer;
import Float = tango.text.convert.Float;

Then you can easily specify which module's function you wanted:

Int.toString(5);
Float.toString(5);

I imagine you could do it similarly with the syntax you identified:

import tango.text.convert.Integer : toString = intToString;
import tango.text.convert.Float : toString = floatToString;

But that is only if you need the toString.  If you wanted to use other 
functions in those modules, then you would use the other method (scoping the 
entire import).

I admit, after writing all this, it does seem unlikely that you would ever 
need to use the import foo : bar = baz.

But I think it would be very useful to import multiple modules from the same 
package.

-Steve
May 15, 2008
Re: Proposal: Package aliases
On 14/05/2008, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
> The more unique

You can't be "more unique". Uniqueness is boolean. :-)
May 15, 2008
Re: Proposal: Package aliases
Janice Caron wrote:
> On 14/05/2008, Bill Baxter <dnewsgroup@billbaxter.com> wrote:
>> The more unique
> 
> You can't be "more unique". Uniqueness is boolean. :-)

Thanks for the info, professor.

--bb
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home