www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - importing modules with non-identifier names

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 31 2009
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sat, Oct 31, 2009 at 12:21:31PM -0500, Andrei Alexandrescu wrote:
 Has anyone been irked by this? 

Yes, quite a bit. I tend to use names-like-this whenever I'm allowed, which includes the filesystem. Of course, it is easy enough to rename the file when doing D.
 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?

I could live with that, but it doesn't seem to work with folders. Let's say I had one called "game-api" with a file inside named "main.d". Would you do something like this: import gameapi.main = "game-api/main.d"; How would that work with the include path? What about: import whatever = "../folder/file.d"; If that was allowed, I'd expect imports to turn into a bit of a mess. Instead of bugging with the -I, you'd just = ".../..." most everything. Then, what about .di files? While I'm irked by the dash import not working, I think the fix here would have more weird corner cases to deal with than is worth it. It is easier to just keep it how it is.
 
 
 Andrei

-- Adam D. Ruppe http://arsdnet.net
Oct 31 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 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.

It's a small limitation, but in practice I don't think it will cause significant problems. And it can be seen as a way to keep module names cleaner. The module system has way larger problems that need to be fixed first. I may even like to further restrict identifiers allowed as module names: only ones that start with a lowercase. This enforces an already existing style guide of D, see "Naming Conventions: Module": http://www.digitalmars.com/d/2.0/dstyle.html Bye, bearophile
Oct 31 2009
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
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?

It's just one of a great many cases which would be fixed by introducing __identifier("XXX"). (That's also a construct which would do wonders for string mixins, BTW).
Oct 31 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
On 31/10/2009 20:58, Don wrote:
 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?

It's just one of a great many cases which would be fixed by introducing __identifier("XXX"). (That's also a construct which would do wonders for string mixins, BTW).

This could be done by adding a Symbol type a-la Ruby: auto fifth = new Symbol("5th-element.d"); import fifth; Symbol could also contain logic for handling [de]mangling of symbols: void foo(); auto str = foo.toSymbol.mangled(); this can simplify the language/compiler. all the logic for handling alias would be moved into this type, for example, alias template parameters would be typed as Symbols: template foo(int i, Symbol s) { ... }
Oct 31 2009
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
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.
Oct 31 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 31 2009
parent reply yigal chripun <yigal100 gmail.com> writes:
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.
Nov 01 2009
parent Christopher Wright <dhasenan gmail.com> writes:
yigal chripun wrote:
 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. 

What about public imports? Tango does this. The old import will contain a pragma(msg) telling you what you should import instead, and maybe some aliases in case some functions or types changed names as well.
Nov 01 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 31 de octubre a las 12:21 me escribiste:
 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?

I see this as a non-problem. I usually like short module names, because is something I have to write all the time since I usually use static or aliased imports (to be able to keep track of the origin of each symbol). I even think imports should be "static" by default, but that's another topic. The thing is, the current scheme tends to make you think about short and simple module names; and I like that. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- - Tata Dios lo creó a usté solamente pa despertar al pueblo y fecundar las gayinas. - Otro constrasentido divino... Quieren que yo salga de joda con las hembras y después quieren que madrugue. -- Inodoro Pereyra y un gallo
Oct 31 2009
prev sibling parent Justin Johansson <no spam.com> writes:
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

I'm irked that it seems like you cannot use keywords as module names. Say if one were writing a compiler for the next big language in D, then it would be reasonable to expect that you could have a D source file called scope.d, module.d etc. Unfortunately as a consequence of this you cannot write (with DMD 1 compiler at least) import nextBigLanguage.scope; import nextBigLanguage.module; Maybe there is some work-around but, even if there is a work-around, for something like this, it is not nice. -- Justin Johansson
Nov 21 2009