the point of selective importing

John Reimer John_member at pathlink.com
Mon Jul 10 21:06:13 PDT 2006


In article <e8urqt$2vb2$1 at digitaldaemon.com>, Ameer Armaly says...
>
>I've been hearing everyone toss around ideas concerning how to selectively 
>import symbols from a module, and how to fqn import a module, and I've 
>seriously been wondering: why selectively import at all?  Assuming we get 
>static import (maybe not with that keyword, but you get the point), what's 
>the need for selectively importing if we can just say:

>import std.stdio; // I want writefln!
>static import cool.module; //Has a toString function for a special type.
>static import std.string; //But most of the time I'll be converting ints and 
>such to strings, so I shouldn't have to specify.

There is a reason (I think repeated several times by now) why selective imports
are useful:

# with lib.module1.special.names
#      import func1, Struct1, Class2;

The above func1, Struct1, and Class2 do not need to be prepended with a FQN
within the module that imported it.  So the "with" syntax eliminates the need
for "aliasing" one by one as would be necessary in the "static import" example
(It does the aliasing automatically).  It removes chances of name conflicts the
way aliasing could, but it much simpler manner.  We are not renaming namespaces
here. Walter has demonstrated this technique before.  Furthermore this is just
one aspect or use of the syntax. Their were more functionality discussed
already.

As we pointed out earlier several times, this cuts down on repetition of
"lib.module1.special.names" on each alias line.  Notice with your import
example, you would have to reference the fully qualified name in order to use
the symbol in your module.  Some may like to do this, but I doubt they would in
a large library that pulls in long fully qualified names (also discussed
priorly).

>It might just be me, but IMHO you're trying to mix apples with oranges; 
>either you want fully qualified imports or you want standard imports.  If 
>you desperately want to mix them, then I agree with Walter in that aliases 
>should be just fine; anyone with half a brain will put them right near the 
>import where they can be seen; anyone who doesn't do that is just a bad 
>coder.

Whoever said that a programmer would want to separate the alias and import?  Are
you making up a straw men to pull down?  Postion of alias has nothing to do with
what we are talking about. We are talking about improving the syntax.  Contrary
to what Walter keeps saying, the two are not identical in what they do.  This
has pointed out repeatedly in several posts.  Nobody is talking about moving
aliases all over the code or even necessarily renaming namespaces. That's up to
the programmer and remains so even with the new convention.

I'm going to assume that the detractors here aren't really understanding each
system. Maybe we should post on a wiki somewhere a thorough description of each
system before every attempt to describe each is taken out of context.
Otherwise, nobody should be concerned about the new syntax since it won't affect
those people.  So why contribute to the discussion if you don't want it?  On the
other hand, we are expresing our need and why.

And Walter, you particularly seem to be stirring this pot by repeatedly posting
misinformation.  We have several times demonstrated the difference between the
two systems.  If you don't understand what we are saying is different, please
ask us to clarify rather than adamantly stating in every post that there is
*nothing* different between the two.  The difference has been clearly
demonstrated more than once.  You seem to be refusing to admit it.

Ameer, I appreciate your input, but if you read over the last posts this has all
been covered before.  I'm sure you mean well.  All opinions are valuable, but I
don't think it's helpful to start describing what constitutes a good and bad
programmer.  While your deprecation has no relation to what we are talking
about, the subtelty of your retort is to cast a possible aspersion on anyone not
agreeing with Walter.  That's not helpful.

I want to say one more thing.  Not everyone here contributing to this discussion
are contributers to D (Ameer, I'm not addressing this to you).  It's really
frustrating to have people throw in an opinion when they have not demonstrated a
consistant use of D in larger projects or commited any length of time pushing D
to its limits.  

Several dedicated people here are making these import suggestions based on lots
of time and experience putting D to use in large projects.  It becomes more
evident, in that context, why D is NOT the same as Java, C#, C++, and why it
shouldn't be the same, even in the context of namespaces. It's a complete
mistake to try to cast D in the same mold as those languages, whatever Walter
keeps saying.  D maintains a different aura and seems to invite a new style, all
evidence of a healthy evolution of a language.  Fixing the namespace issues that
crop up with use, and doing it, let me repeat, elegantly is very important to
promoting D's success in larger projects.  

Please remember, if people here are saying there's no issue and yet have not
worked with D in large libraries or projects, I'm afraid I don't see how their
opinion can be a substantial demonstration of evidence.

I've written way more than I should on this topic and it's beginning to wear on
me from having to repeat the same arguments over and over.  I'd be best to step
out now and let things take the course. But I'm assuming the course will
continue to be a limiting one from the direction I see the comments from Walter
and others going. 

Nonetheless... all the best to everyone.

-JJR





More information about the Digitalmars-d mailing list