May 14, 2008
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
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
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
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
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
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
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
"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
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
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