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