importing modules with non-identifier names

[yigal chripun]

Andrei Alexandrescu Wrote:

> Yigal Chripun wrote:
> > On 31/10/2009 19:21, Andrei Alexandrescu wrote:
> >> Has anyone been irked by this? If you have a module called 5th-element.d
> >> there is no way to import that. I don't think it's a major issue, but
> >> I'm also seeing it as a limitation that should have a better explanation.
> >>
> >> One way to circumvent that may be
> >>
> >> import fifth = "5th-element.d";
> >>
> >> i.e., specify the file as a string and assign to it a regular D
> >> identifier. Probably similar things have been discussed in the past,
> >> what's the general impression?
> >>
> >>
> >> Andrei
> > 
> > IMO physical storage should be orthogonal to logical structure of the 
> > code. This is why I like the C# way of namespaces. Each assembly knows 
> > what namespace(s) it contains so the compiler can figure out what 
> > assembly to use when you use a namespace.
> > I might want to store a single namespace/package in multiple folders, 
> > for example to separate the implementation into /win32 /linux etc...
> > 
> > The downside to this is that it's a little more complicated.
> > The tool chain should also provide a reverse lookup from a 
> > symbol/namespace to any assemblies that contain it, probably a compiler 
> > flag.
> 
> Well I was just growing fonder of the fact that there's a 1:1 
> correspondence between file and module, and between package and 
> directory. It's simple, easy to explain, and benefits of everything the 
> OS offers in terms of management.
> 
> Also, to me it looks like files and directories are subject to similar 
> scale issues as modules and packages.
> 
> 
> Andrei

Yes, it's a little simpler but also less flexible. This 1:1 mapping has all the benefits and also all the drawbacks of the OS management. For instance, there the issue of case sensitivity: D is case sensitive but the win FS isn't.

This tight mapping is also a problem when you want to rearange physical structure without affecting the API -  e.g. a module had grown to be too big and you want to split it into multiple files. std.algorithm is a prime example of such way too big module. 

I agree that fully separating the two concepts is more complex but the current system is just too strict to my liking. At least some compromise solution that allows more flexibility is needed.