the point of selective importing

[rko]

In article <e8v83l$jfo$1 at digitaldaemon.com>, John Reimer says...
>
>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.
>

that would be neat. why not do it as it is/was in iso modula-2?
from lib.module1.special.names import func1, Struct1, Class2;
//(http://www.arjay.bc.ca/Modula-2/Text/index.html)

>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
>
>
could't agree more

rko