www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D's import and alias are very nice

reply "Ben Hinkle" <bhinkle mathworks.com> writes:
The newsgroup is a bit slow lately so I just want to say I really like D's
import and alias mechanisms. For example I've been writing MinWin and I have
a class called Window in module minwin.window and it conflicts with the
Motif symbol called Window (in MinWin I put the Motif declarations in a
module called minwin.motif). So I was worried that I'd have to constantly be
specifying which Window I wanted or have to stick ugly prefixes on my
symbols like MWWindow or something. But I've found that "private import" and
(sometimes) an alias gets the job done very nicely. The minwin.window module
private imports minwin.motif (at least when compiling with motif) so anyone
that imports minwin.window doesn't have to worry about any conflict unless
they also need something from minwin.motif. In those modules where I need to
import both minwin.window and minwin.motif and I need to use the Window
symbol but only from minwin.window I can do something like
 import minwin.window;
 import minwin.motif;
 alias minwin.window.Window MWWindow;
and then use MWWindow without any problems. Also by using "private import" I
can cut down the number of possible conflicts so that you pretty much have
to explicitly import two module with the same symbol in order to get any
conflict and then either using an alias or just writing out the fully
qualified symbol works great.
Anyhow, I've found D's mechanism is better than C++'s #include with symbol
prefixes or #include with "using namespace" or whatever. The default D
behavior is usually just what I want and it is easy to deal with conflicts.

-Ben
Jan 10 2005
parent reply kris <kris_member pathlink.com> writes:
Without question, import should be 'private' by default (IMO). Various people
have been asking for this since ~last-April/May, and I don't recall anyone
arguing otherwise. In hindsight, those requests were perhaps one of the very few
things that didn't cause an vast uproar of one kind or another; yet the default
is still 'public' ... go figure!

Apparently the only thing that 'alias' doesn't do is make the Tea ... that's not
a good sign, and its usage with respect to method-name resolution is dodgy at
best (IMO). It certainly is good at doing what you describe, Ben.



In article <crulng$1sul$1 digitaldaemon.com>, Ben Hinkle says...
The newsgroup is a bit slow lately so I just want to say I really like D's
import and alias mechanisms. For example I've been writing MinWin and I have
a class called Window in module minwin.window and it conflicts with the
Motif symbol called Window (in MinWin I put the Motif declarations in a
module called minwin.motif). So I was worried that I'd have to constantly be
specifying which Window I wanted or have to stick ugly prefixes on my
symbols like MWWindow or something. But I've found that "private import" and
(sometimes) an alias gets the job done very nicely. The minwin.window module
private imports minwin.motif (at least when compiling with motif) so anyone
that imports minwin.window doesn't have to worry about any conflict unless
they also need something from minwin.motif. In those modules where I need to
import both minwin.window and minwin.motif and I need to use the Window
symbol but only from minwin.window I can do something like
 import minwin.window;
 import minwin.motif;
 alias minwin.window.Window MWWindow;
and then use MWWindow without any problems. Also by using "private import" I
can cut down the number of possible conflicts so that you pretty much have
to explicitly import two module with the same symbol in order to get any
conflict and then either using an alias or just writing out the fully
qualified symbol works great.
Anyhow, I've found D's mechanism is better than C++'s #include with symbol
prefixes or #include with "using namespace" or whatever. The default D
behavior is usually just what I want and it is easy to deal with conflicts.

-Ben
Jan 10 2005
next sibling parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <crv855$2ikm$1 digitaldaemon.com>, kris says...
Without question, import should be 'private' by default (IMO). Various people
have been asking for this since ~last-April/May, and I don't recall anyone
arguing otherwise. In hindsight, those requests were perhaps one of the very few
things that didn't cause an vast uproar of one kind or another; yet the default
is still 'public' ... go figure!
yeah, though I don't really mind either way. It's tough to say if private-by-default would confuse the heck out of noobies - I don't really know.
Apparently the only thing that 'alias' doesn't do is make the Tea ... that's not
a good sign, and its usage with respect to method-name resolution is dodgy at
best (IMO). It certainly is good at doing what you describe, Ben.
What do you mean by not a good sign? Is it too powerful? It seems pretty focused to me. Abut method-names... I vaguely remember something about that but if there's a link handy to the issues I would like to see what the issue is. Then again I only import at the start of the module and that's also where I put all my aliases for module clashes. I remember hearing about lots of issues with importing in class definitions and such.
Jan 10 2005
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 What do you mean by not a good sign? Is it too powerful? It seems pretty
focused
 to me.
Well it seems to kind of provide a trapdoor through the otherwise orderly name resolution of D. It's definitely needed sometimes, but I sometimes wonder if it's only needed as much as it is because D imports all module symbols into the current namespace.. if we had to explicitly qualify identifiers using the module.id syntax, alias would only really be useful to shorten commonly used identifiers to something a little more easily typeable. Instead, we use it to clear up name conflicts that wouldn't happen if we were forced to use the fully qualified names.
Jan 11 2005
parent Ben Hinkle <Ben_member pathlink.com> writes:
In article <cs22a2$47e$1 digitaldaemon.com>, Jarrett Billingsley says...
 What do you mean by not a good sign? Is it too powerful? It seems pretty
focused
 to me.
Well it seems to kind of provide a trapdoor through the otherwise orderly name resolution of D. It's definitely needed sometimes, but I sometimes wonder if it's only needed as much as it is because D imports all module symbols into the current namespace.. if we had to explicitly qualify identifiers using the module.id syntax, alias would only really be useful to shorten commonly used identifiers to something a little more easily typeable. Instead, we use it to clear up name conflicts that wouldn't happen if we were forced to use the fully qualified names.
But that's already true, no? I suppose I didn't have to use alias to resolve conflicts but I'm too lazy to type out something like minwin.window.Window more than a couple times per file so I make an alias.
Jan 11 2005
prev sibling parent reply Kramer <Kramer_member pathlink.com> writes:
Forgive me if this question is nieve or has been answered but, what are the
benefits to having imports 'public' by default?  I keep seeing this topic pop up
and I don't really understand it from the point of language
design/effeciency/error reduction.  Does it make the compiler faster or the
language less prone to hidden bugs?  I understand that it means there's more
potential for name conflicts but surely other languages have done it this way
and not had too many problems, no?  Or is this topic more of a personal
preference in the way the developer codes?

I apologize for all the questions, but I'm really hoping someone can answer
this.

Thanks in advance,
Kramer

In article <crvj80$2v4n$1 digitaldaemon.com>, Ben Hinkle says...
In article <crv855$2ikm$1 digitaldaemon.com>, kris says...
Without question, import should be 'private' by default (IMO). Various people
have been asking for this since ~last-April/May, and I don't recall anyone
arguing otherwise. In hindsight, those requests were perhaps one of the very few
things that didn't cause an vast uproar of one kind or another; yet the default
is still 'public' ... go figure!
yeah, though I don't really mind either way. It's tough to say if private-by-default would confuse the heck out of noobies - I don't really know.
Apparently the only thing that 'alias' doesn't do is make the Tea ... that's not
a good sign, and its usage with respect to method-name resolution is dodgy at
best (IMO). It certainly is good at doing what you describe, Ben.
What do you mean by not a good sign? Is it too powerful? It seems pretty focused to me. Abut method-names... I vaguely remember something about that but if there's a link handy to the issues I would like to see what the issue is. Then again I only import at the start of the module and that's also where I put all my aliases for module clashes. I remember hearing about lots of issues with importing in class definitions and such.
Jan 12 2005
parent Thomas Kuehne <thomas-dloop kuehne.thisisspam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kramer schrieb am Wed, 12 Jan 2005 16:33:44 +0000 (UTC):
 Or is this topic more of a personal
 preference in the way the developer codes?
The public imports come from the default public access to class members, functions etc. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFB5VXm3w+/yD4P9tIRAguwAJ9Y9GD6qlTCJ/XWuMqAkFMSe/7+IwCgwQ/k H0kXoveTG+MpNUhO9m47Iq0= =c0rq -----END PGP SIGNATURE-----
Jan 12 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"kris" <kris_member pathlink.com> wrote in message
news:crv855$2ikm$1 digitaldaemon.com...
 Without question, import should be 'private' by default (IMO). Various
people
 have been asking for this since ~last-April/May, and I don't recall anyone
 arguing otherwise. In hindsight, those requests were perhaps one of the
very few
 things that didn't cause an vast uproar of one kind or another; yet the
default
 is still 'public' ... go figure!
The reason it is public by default is for consistency with class member access being default public and module level symbols being default public. The default public makes it easier to write quick & dirty programs. Only when a program exceeds a certain level of complexity does it become worthwhile to start using private and access protection.
Jan 12 2005
parent reply rev <rev_member pathlink.com> writes:
In article <cs49st$ci0$1 digitaldaemon.com>, Walter says...
"kris" <kris_member pathlink.com> wrote in message
news:crv855$2ikm$1 digitaldaemon.com...
 Without question, import should be 'private' by default (IMO). Various
people
 have been asking for this since ~last-April/May, and I don't recall anyone
 arguing otherwise. In hindsight, those requests were perhaps one of the
very few
 things that didn't cause an vast uproar of one kind or another; yet the
default
 is still 'public' ... go figure!
The reason it is public by default is for consistency with class member access being default public and module level symbols being default public. The default public makes it easier to write quick & dirty programs. Only when a program exceeds a certain level of complexity does it become worthwhile to start using private and access protection.
Walter this is rediculous. I agree, consistency is very important in the langauage. However, in the case of imports it pays to deviate from the consistency principle. It is far better to break consistency in this case because in doing so it provides an overall improvement on the language. Even in "quick & dirty" programs, most of us here choose to import the modules that contain the functionalities we need rather that relying on their existence in some previously imported module. Bar none, this is the most prevalent cause of conflicts in D thus far. Yes we can avoid these confilcts with the use of "private import", aliases, and explicit access (e.g. std.somemoduale.somefunc()). But this is hardly an ideal. An overwhelming amount of here would welcome this deviation. I might even go out on a limb to say that you are the only one left here holding on to the "need or desire" for a public imports being the default. And you know what the scary thing is? I might be right! Ciao, Rev
Jan 12 2005
next sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
rev wrote:

 In article <cs49st$ci0$1 digitaldaemon.com>, Walter says...
"kris" <kris_member pathlink.com> wrote in message
news:crv855$2ikm$1 digitaldaemon.com...
 Without question, import should be 'private' by default (IMO). Various
people
 have been asking for this since ~last-April/May, and I don't recall
 anyone arguing otherwise. In hindsight, those requests were perhaps one
 of the
very few
 things that didn't cause an vast uproar of one kind or another; yet the
default
 is still 'public' ... go figure!
The reason it is public by default is for consistency with class member access being default public and module level symbols being default public. The default public makes it easier to write quick & dirty programs. Only when a program exceeds a certain level of complexity does it become worthwhile to start using private and access protection.
Walter this is rediculous. I agree, consistency is very important in the langauage. However, in the case of imports it pays to deviate from the consistency principle. It is far better to break consistency in this case because in doing so it provides an overall improvement on the language.
I can only agree on that! (Even though, I might not have used the same words... :-) class members any imports clearly are two distinct concepts. The words "public" and "protected" have a rather different meaning. Both concepts are so basic to the language, that users should not have a problem remembering within a short while. Defaults are not just a means of saving typing but also of guiding the style that programmers use. public imports definitely are bad style if used without necessity. If a dummy programmer writes a library without thinking, he will use the default. In the current setting, he will never be forced to think about it until he passes the library to someone else, who get the namespace clogged with garbage and has to start a discussion with the original author. If imports were private by default, he would never have to think about it either, but nobody else would complain about it either. The notion about quick-and-dirty programming: I would think that as soon as someone uses more than two or three modules for a project, he should already have left the stage of quick-and-dirty... Greetings, Norbert
Jan 13 2005
prev sibling parent reply Ben Hinkle <Ben_member pathlink.com> writes:
[snip]
I agree, consistency is very important in the
langauage. However, in the case of imports it pays to deviate from the
consistency principle. It is far better to break consistency in this case
because in doing so it provides an overall improvement on the language.
Isn't that principle obvious? The only question is does it improve the language overall.
Even in "quick & dirty" programs, most of us here choose to import the modules
that contain the functionalities we need rather that relying on their existence
in some previously imported module. Bar none, this is the most prevalent cause
of conflicts in D thus far. Yes we can avoid these confilcts with the use of
"private import", aliases, and explicit access (e.g.
std.somemoduale.somefunc()). But this is hardly an ideal. 
To dig into the root cause of wanting private imports I'd like to find out where conflicts come from and how common they really are in practise. For me the conflict with Window came because I was creating a wrapper class around another class that was platform specific and one of the platforms happened to use the same name as the one I wanted. I'm guessing there are other examples that come from importing a phobos module and it happens to use a nice functionn name or something, but nothing springs to mind. It seems pretty rare that a set of names being used within one codebase would conflict. I'm starting to convince myself the default should be "package" - or kept as public like everything else. The only issue I have really with imports is the error message you get when you have a conflict doesn't give a clue about the import chain so you have to start digging around to find out who did the public import when they shouldn't have. When import chains get three or four deep with recursion it can get complicated to find the bug.
An overwhelming amount of here would welcome this deviation. 
uhh, for the record I don't care which way it is.
Jan 13 2005
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Ben Hinkle wrote:
I agree, consistency is very important in the
langauage. However, in the case of imports it pays to deviate from the
consistency principle. It is far better to break consistency in this case
because in doing so it provides an overall improvement on the language.
Isn't that principle obvious? The only question is does it improve the language overall.
The key question is not: "Which default is more practical for the programmer?", but: "What will the third-party libraries look like if we assume that many people stick with the default without thinking about the consequences?" Exactly, but for that question, you will have to forecast where each decision might lead the language in the long term. Currently, libraries and packages are rather small and few. Of course, so far, conflicts are a rather rare event. To look further into the future of D, we can only try to learn from other languages. One language that I'm using quite intensively at the moment is Python. One of my worst experiences here is to work with a mixture of numarray, Numeric, SciPy and matplotlib. These are four numerics packages that are developed by different groups but strongly interdependent. The packages import each other, modify details and reexport each other again. Basically, Python only knows public imports, meaning that many symbols can be imported via many different sources. Moreover, since the functinality is similar, many symbols are similar or identical. Now, if you know about a symbol "array", you will soon find out that each of the four packages exports "array". numarray and Numerics both define different classes by the symbol "array", so there clearly is a conflict. SciPy and matplotlib both reexport the symbol "array" coming from one of the former libraries. Of course, there are tools to sort this out, but at first, you definitely are confused. There is no problem with conflicts: they can be solved in a similar way as in D. Still - if every module from a package exports a mixture of symbols from all kinds of sources, you completely loose track of the actual structure of the package. (Same thing for C header files: once you include one, you get all kinds of symbols into your namespace. I you look at some random C file, the list of included headers would usually tell you nothing about what the file actually uses, but only give some selection of includes that happen to provide everything that is needed.) What I have in mind for D would be something like: packages of interdependent modules. Each of them doing private imports from others and only exports a clearly defined, distinct set of symbols. In addition, there could be one "meta-module" that does not define any symbols itself, but just has a list of public imports of all modules in the package. Now, if you use the package, you can decide whether you import some modules selectively or just do a import of the meta-module, getting all symbols. Of course, this setup will be possible no matter what the default for imports is. Anyhow: it is clear from this picture that you would usually want to do private imports unless you have special needs. Again, the key question is not: "Which default is more practical for the programmer?", but: "What will the third-party libraries look like if we assume that many people stick with the default without thinking about the consequences?"
Jan 13 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
[snip]
 What I have in mind for D would be something like: packages of
 interdependent modules. Each of them doing private imports from others and
 only exports a clearly defined, distinct set of symbols. In addition,
there
 could be one "meta-module" that does not define any symbols itself, but
 just has a list of public imports of all modules in the package.

 Now, if you use the package, you can decide whether you import some
modules
 selectively or just do a import of the meta-module, getting all symbols.
It is true that one can view declarations in a module as basically the opposite of importing a module. By declaring something you are telling the world about this new thing but with importing you are asking the world for something. So I can see how one could argue new users wouldn't be confused that a declaration is public by default but imports are private by default. It's like a yin/yang situation. Right now D is all yang and no yin. :-) The other view is that import is adding declarations to the scope just without definitions so it's almost the same as declaring something and hence should be public by default. I do agree though that default public will result in more potential conflicts - but will mean fewer imports at the top of files. Like in Java sometimes you get these import blocks at the tops of files with tons of imports and it just gets pretty annoying IMO. I don't think Java has the concept of public/private imports - everything is private. [snip]
Jan 13 2005
parent Norbert Nemec <Norbert Nemec-online.de> writes:
Ben Hinkle wrote:
 The other view is that import is adding declarations to the scope just
 without definitions so it's almost the same as declaring something and
 hence should be public by default.
Exactly this "almost" is the problem. Of course, to the outside world, a native symbol and a publicly imported symbol look the same. But if this happens without care, suddenly every symbol seems to be part of every module, you loose track of the actual place of definition of symbols and the structure of a library gets blurry.
 I do agree though that default public will result in more potential
 conflicts - but will mean fewer imports at the top of files. Like in Java
 sometimes you get these import blocks at the tops of files with tons of
 imports and it just gets pretty annoying IMO.  I don't think Java has the
 concept of public/private imports - everything is private.
That's exactly the problem of Java. But in D we have public imports as well, so there is nobody hindering you wring meta-modules that only contain public imports. Each library could just have such meta-modules allowing you to import groups of modules at once. In an application, you could also have one central module that imports all the libraries that are needed and solves conflicts, so you just have to import this one module in every source file. Anyhow, such collections should be done deliberately and not just because people were too lazy to write the word "private".
Jan 13 2005