Import concerns revisited

[John Reimer]

>>
>> "Walter Bright" <newshound at digitalmars.com> wrote in message 
>> news:e8utvp$53$1 at digitaldaemon.com...
>>> John Reimer wrote:
>>>> If you can find something
>>>> equivalent to from/as (which you most certainly haven't), without 
>>>> adopting new
>>>> syntax, maybe we'll bite... but so far, I think using 'with' (or from) 
>>>> and 'as'
>>>> is an excellent contender.
>>>
>>> I'll repeat myself here, too <g>. The 'static import' combined with 
>>> 'alias' has
>>>
>>> *exactly the same semantics*
>>>
>>> as 'with' 'as'. The only difference between the proposals is if there 
>>> are two statements or one. There is no difference in power or effect. 
>>> There is nothing that one can do that the other cannot.
>>>
>>
>>
>> The semantics are not exactly the same.  Read Sean and Kris's 
>> explanations again, please.  'static import' adds nothing to the what 
>> this whole namespace business.  It just sharpens the compiler a bit to 
>> enforce FQN for the programmer's sake.  But that is absolutely 
>> unnecessary because a D programmer that wants to do that now can just 
>> make sure he uses FQNs!  So what's the point of 'static import'?
>
> I have to disagree with this. Currently, suppose you have a module that 
> uses the toString() functions from std.string (and uses them hundreds of 
> times). Then, you decide you need to use std.date in one place to get the 
> current time. Suddenly, your module won't compile, because 
> std.date.toString() conflicts with all the other toString()s that you're 
> using. Even though you're not even using std.date.toString !
>

Fair enough.

I've seen this error also on several occasions.  I can't remember the exact 
source of it, but I think it's related to another issue.  It was my 
understanding that that was due to public imports somewhere up the line. 
This might have been one of the reasons why discussions started concerning a 
borked import system.  Perhaps I'm wrong?

There used to be confusion relating to D's name lookup mechanism. Importing 
a module into a class declaration was a huge mess, because people didn't 
realize how name lookup worked in D.


> With the static import proposal, you could just have
>
> import std.string;
> static import std.date;
>
> and then use FQNs for the single usage of date.
>


Er.. that tells me more that there's a problem with the original mechanism. 
And "static import" is a workaround.  Why not fix the original import 
system?  There must be something wrong with it.  So are we adding new 
constructs to workaround name clashes? Is that a good idea?  Is that the 
reason 'static import' was suggested?  There shouldn't be name clashes when 
fully qualified names are used in the first place! If there are, that's an 
unrelated problem and should be addressed and fixed, apart from this whole 
thread before we proceed.


> This is not a contrived example, I encountered it in my second D program 
> (and I immediately thought that there were serious problems with the D 
> module system. You're telling me I have to alias std.string.toString just 
> because I want to use std.date.getUTCtime() ???). 'static import' would 
> make it possible to avoid the use of FQNs in most cases; it would enable 
> you to distinguish 'I'm going to use a function from this module' (static 
> import) from 'I'm heavily depending on this module' (normal import).
>


I say 'static import' is a cheap fix for a major problem in the import 
system, then. :P


> Which is not to say that I'm favouring 'static import' in this discussion, 
> I'm simply saying that all of the proposals, including static import, are 
> an *enormous* improvement over what we have now.


I understand. But I still think that using 'static import' as a fix is not 
the solution.

-JJR
what we have now.