For example:

    * static import io = std.stdio;
    * import io = std.stdio;

We must use io prefix to access std.stdio, in above two situation.

In article <e9k8bv$2usv$1@digitaldaemon.com>, Boris Wang says...
>
>For example:
>
>    * static import io = std.stdio;
>    * import io = std.stdio;
>


Good question.  Have you tested these first to see what happens or if the first even works?  I think that might answer your question.  Then you can tell those of us who haven't had a chance to try yet. :)

-JJR

On Wed, 19 Jul 2006 06:14:11 +0000 (UTC), John Reimer wrote:

> In article <e9k8bv$2usv$1@digitaldaemon.com>, Boris Wang says...
>>
>>For example:
>>
>>    * static import io = std.stdio;
>>    * import io = std.stdio;
>>
> 
> Good question.  Have you tested these first to see what happens or if the first even works?  I think that might answer your question.  Then you can tell those of us who haven't had a chance to try yet. :)
> 

There is no difference. They function in an identical manner.

  static import XXX;
  import XXX = whatever;
  static import XXX = whatever;

all require that 'XXX' be used to reference members in the code.

However, if you decide to allow non-FQN all you have to do is *add* the line 'import XXX;' somewhere in your module and all the FQN requirements disappear.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
19/07/2006 4:22:03 PM

In article <9vh8joe3sla0.1se36qil8397i$.dlg@40tude.net>, Derek Parnell says...
>
>On Wed, 19 Jul 2006 06:14:11 +0000 (UTC), John Reimer wrote:
>
>> In article <e9k8bv$2usv$1@digitaldaemon.com>, Boris Wang says...
>>>
>>>For example:
>>>
>>>    * static import io = std.stdio;
>>>    * import io = std.stdio;
>>>
>> 
>> Good question.  Have you tested these first to see what happens or if the first even works?  I think that might answer your question.  Then you can tell those of us who haven't had a chance to try yet. :)
>> 
>
>There is no difference. They function in an identical manner.
>
>  static import XXX;
>  import XXX = whatever;
>  static import XXX = whatever;
>
>all require that 'XXX' be used to reference members in the code.
>
>However, if you decide to allow non-FQN all you have to do is *add* the line 'import XXX;' somewhere in your module and all the FQN requirements disappear.
>

Ah... ok. Good to know. I guess we have a very flexible system in place, capable of accomodating several styles.  And Walter gets to have his "static import" as well. :)

-JJR

"John Reimer" <John_member@pathlink.com> дÈëÏûÏ¢ÐÂÎÅ:e9knp5$fk1$1@digitaldaemon.com...
> In article <9vh8joe3sla0.1se36qil8397i$.dlg@40tude.net>, Derek Parnell says...
>>
>>On Wed, 19 Jul 2006 06:14:11 +0000 (UTC), John Reimer wrote:
>>
>>> In article <e9k8bv$2usv$1@digitaldaemon.com>, Boris Wang says...
>>>>
>>>>For example:
>>>>
>>>>    * static import io = std.stdio;
>>>>    * import io = std.stdio;
>>>>
>>>
>>> Good question.  Have you tested these first to see what happens or if
>>> the first
>>> even works?  I think that might answer your question.  Then you can tell
>>> those
>>> of us who haven't had a chance to try yet. :)
>>>
>>
>>There is no difference. They function in an identical manner.
>>
>>  static import XXX;
>>  import XXX = whatever;
>>  static import XXX = whatever;
>>
>>all require that 'XXX' be used to reference members in the code.
>>
>>However, if you decide to allow non-FQN all you have to do is *add* the line 'import XXX;' somewhere in your module and all the FQN requirements disappear.
>>
>
> Ah... ok. Good to know. I guess we have a very flexible system in place,
> capable
> of accomodating several styles.  And Walter gets to have his "static
> import" as
> well. :)
>
> -JJR
>
>
>

No, I don't think so.

Something need refining.

Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it.

For example

int main(void)
{
    std.stdio.writefln("Just do it"); // not need any importing
    ...
}

In article <e9kp1b$hcm$1@digitaldaemon.com>, Boris Wang says...
>
>
>> Ah... ok. Good to know. I guess we have a very flexible system in place,
>> capable
>> of accomodating several styles.  And Walter gets to have his "static
>> import" as
>> well. :)
>>
>> -JJR
>>
>>
>>
>
>No, I don't think so.
>
>Something need refining.
>
>Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it.
>
>For example
>
>int main(void)
>{
>    std.stdio.writefln("Just do it"); // not need any importing
>    ...
>}
>
>

Yes, I understand that there's a bit of a redundancy in the current implementation, but I'm not sure the above solution is good one or really necessary.  An import statement seems to give the compiler a quick lookup hint, and meanwhile acts as a documentation tool indicating which module is going to be used in a program.

The above is certainly a possibility for what might be termed "implied importing".  But I'm not quite comfortable with it.  At this point, I don't have any comments to the negative other than that, for the time being, I think we have pushed the import issue far enough. :)

-JJR

John Reimer wrote:
> In article <e9kp1b$hcm$1@digitaldaemon.com>, Boris Wang says...
>>
>>> Ah... ok. Good to know. I guess we have a very flexible system in place, capable
>>> of accomodating several styles.  And Walter gets to have his "static import" as
>>> well. :)
>>>
>>> -JJR
>>>
>>>
>>>
>> No, I don't think so.
>>
>> Something need refining.
>>
>> Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it.
>>
>> For example
>>
>> int main(void)
>> {
>>    std.stdio.writefln("Just do it"); // not need any importing
>>    ...
>> }
>>
>>
> 
> Yes, I understand that there's a bit of a redundancy in the current
> implementation, but I'm not sure the above solution is good one or really
> necessary.  An import statement seems to give the compiler a quick lookup hint,
> and meanwhile acts as a documentation tool indicating which module is going to
> be used in a program.
> 
> The above is certainly a possibility for what might be termed "implied
> importing".  But I'm not quite comfortable with it.  At this point, I don't have
> any comments to the negative other than that, for the time being, I think we
> have pushed the import issue far enough. :)
> 
> -JJR
> 
> 

List time I checked this was not implemented in D. For that matter it has never been implemented in D. If you want to reference a function in a module you have to import the module or, in the case of the most recent implementation, selectively import from the module in order to access the desired functionality.

As I understand it, the question Boris is asking is why do this:

| import std.string;
| void main()
| {
|   writefln("Now I can use it");
| }

When you can do this:

| //import nothing
| void main()
| {
|   std.string.writefln("Here I simply use it");
| }

I think he's got a point.

The compiler already knows how to find std.string and it can decipher whether or not a requested functionality is implemented in the module. Therefore it should be smart enough to *implicitly* import that function/module using FQNs alone.

Andrew C. Edwards

In article <e9l4se$1789$1@digitaldaemon.com>, Tyro says...

>The compiler already knows how to find std.string and it can decipher whether or not a requested functionality is implemented in the module. Therefore it should be smart enough to *implicitly* import that function/module using FQNs alone.

Yes, I believe we all understand this. But as JJR already said it quite well, I think the import issues are solved for now. An explicit import statement is more self documenting and it's helping tools like Build and IDE's with the name lookup.

-- 
Jari-Matti

Tyro wrote:
> John Reimer wrote:
>> In article <e9kp1b$hcm$1@digitaldaemon.com>, Boris Wang says...
>>>
>>>> Ah... ok. Good to know. I guess we have a very flexible system in place, capable
>>>> of accomodating several styles.  And Walter gets to have his "static import" as
>>>> well. :)
>>>>
>>>> -JJR
>>>>
>>>>
>>>>
>>> No, I don't think so.
>>>
>>> Something need refining.
>>>
>>> Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it.
>>>
>>> For example
>>>
>>> int main(void)
>>> {
>>>    std.stdio.writefln("Just do it"); // not need any importing
>>>    ...
>>> }
>>>
>>>
>>
>> Yes, I understand that there's a bit of a redundancy in the current
>> implementation, but I'm not sure the above solution is good one or really
>> necessary.  An import statement seems to give the compiler a quick lookup hint,
>> and meanwhile acts as a documentation tool indicating which module is going to
>> be used in a program.
>>
>> The above is certainly a possibility for what might be termed "implied
>> importing".  But I'm not quite comfortable with it.  At this point, I don't have
>> any comments to the negative other than that, for the time being, I think we
>> have pushed the import issue far enough. :)
>>
>> -JJR
>>
>>
> 
> List time I checked this was not implemented in D. For that matter it has never been implemented in D. If you want to reference a function in a module you have to import the module or, in the case of the most recent implementation, selectively import from the module in order to access the desired functionality.
> 
> As I understand it, the question Boris is asking is why do this:
> 
> | import std.string;
> | void main()
> | {
> |   writefln("Now I can use it");
> | }
> 
> When you can do this:
> 
> | //import nothing
> | void main()
> | {
> |   std.string.writefln("Here I simply use it");
> | }
> 
> I think he's got a point.
> 
> The compiler already knows how to find std.string and it can decipher whether or not a requested functionality is implemented in the module. Therefore it should be smart enough to *implicitly* import that function/module using FQNs alone.
> 
> Andrew C. Edwards

But how does it know that std.string is a module? It could be a sequence of classes, for example.

class std {
 class string {
   void writefln(str[]...);
 }
}

If you're not using anything from std, I think that would be perfectly legal. Unlikely in the case of std.string, but in general...

Declaring imports is IMHO a lot like declaring variables. Not strictly necessary, but it saves you from lots of hard-to-track down bugs.

In article <e9kp1b$hcm$1@digitaldaemon.com>, Boris Wang says...
>
>Why not discard the sentence 'static import' ? When you need FQN to access a package, just do it.
>
>For example
>
>int main(void)
>{
>    std.stdio.writefln("Just do it"); // not need any importing
>    ...
>}
>

This won't work because its not guaranteed to be non-ambiguous.  Thanks to how D layous out namespaces, the FQN "std.stdio.writefln" isn't necessarily the method "writefln" in module "std.stdio".  For example, the following module:

// std.d
module std;
struct stdio{
class writefln{
static opCall(){ /*...*/ }
}
}

.. could be placed on DMD's include path and match the 'implicit' import you describe above.

This more or less requires a series of compiler behaviors, none of which are a really good idea IMO.  Should the compiler accept all possible variants of an FQN for matching, then you get this in the worst case for *every* FQN:

- Parse *all* files on the current include path for matching FQN's
- Report an ambiguious match as either an error or warning
- In the case of a warning, pick one of the matching modules for inclusion and
continue.

- EricAnderton at yahoo