Import concerns revisited

[John Reimer]

Actually, I just want to make a correction.  The problem you describe, Don, 
is very much related to this whole issue (after I did some reading up on the 
name collision thing to understand it more), but I still don't consider the 
"static import" a proper fix.

-JJR


"Don Clugston" <dac at nospam.com.au> wrote in message 
news:e8vn6d$1bm0$1 at digitaldaemon.com...
> John Reimer wrote:
>>
>> "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 !
>
> 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.
>
> 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).
>
> 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.