Thread overview | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 19, 2006 what's the difference between 'static import =' and 'import ='? | ||||
---|---|---|---|---|
| ||||
For example: * static import io = std.stdio; * import io = std.stdio; We must use io prefix to access std.stdio, in above two situation. |
July 19, 2006 Re: what's the difference between 'static import =' and 'import ='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Boris Wang | 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 |
July 19, 2006 Re: what's the difference between 'static import =' and 'import ='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | 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 |
July 19, 2006 Re: what's the difference between 'static import =' and 'import ='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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 |
July 19, 2006 Re: what's the difference between 'static import =' and 'import ='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | "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 ... } |
July 19, 2006 Re: what's the difference between 'static import =' and 'import ='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Boris Wang | 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 |
July 19, 2006 Re: what's the difference between 'static import =' and 'import ='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Reimer | 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
|
July 19, 2006 Re: what's the difference between 'static import =' and 'import ='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tyro | 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 |
July 19, 2006 Re: what's the difference between 'static import =' and 'import ='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Tyro | 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.
|
July 19, 2006 Re: what's the difference between 'static import =' and 'import ='? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Boris Wang | 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 |
Copyright © 1999-2021 by the D Language Foundation