importing modules with non-identifier names

[Andrei Alexandrescu]

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