Boris Wang wrote:
> "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
>     ...
> }
> 
> 

I could only be comfortable with this if it only worked with the standard library (things in the std package). And even then, it might require that people can't name things 'std'.

Nah, I prefer explicit imports.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://dsource.org/projects/pyd/wiki

pragma wrote:
> 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

Forget the option of reporting an warning. Such situation should be an error, just as this is:
  import pack;
  import pack.foo; // pack conflicts.

And the the compiler search behavior would be complicated. For an access like:
  x.y.z.foo();

Then for each path in the include path, search the root dir for a x module or package. If there is more than one match (or no matches) report an error. Otherwise, use the found match, and recurse the search.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Boris Wang wrote:
> "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
>     ...
> }
> 
> 

I like the idea of FQN access automatically available for all modules, but the way I'd like that to be done is not for the compiler to try to implicitly search and import modules when encountering unknown names (like the 'std.stdio.writefln' in the example above).
Rather, the whole set of modules that a program uses could be set at the start, by compiler options (or the fqnall trick). This would avoid the name issues mentioned by pragma and Don (the "class std {...}") as well as allow an IDE to show completion for the available modules&packages.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Boris Wang wrote:
>> "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
>>     ...
>> }
>>
>>
> 
> I like the idea of FQN access automatically available for all modules, but the way I'd like that to be done is not for the compiler to try to implicitly search and import modules when encountering unknown names (like the 'std.stdio.writefln' in the example above).
> Rather, the whole set of modules that a program uses could be set at the start, by compiler options (or the fqnall trick). This would avoid the name issues mentioned by pragma and Don (the "class std {...}") as well as allow an IDE to show completion for the available modules&packages.

Well, you can do this already with a
----
module usingphobos;
public import stdio = std.stdio;
public import string = std.string;
(etc)


----
import usingphobos;

void main()
{
    stdio.writefln("Yes it works!");
}
----
All it takes is a single import at the top of each file.

Don Clugston wrote:
> Bruno Medeiros wrote:
>> Boris Wang wrote:
>>> "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
>>>     ...
>>> }
>>>
>>>
>>
>> I like the idea of FQN access automatically available for all modules, but the way I'd like that to be done is not for the compiler to try to implicitly search and import modules when encountering unknown names (like the 'std.stdio.writefln' in the example above).
>> Rather, the whole set of modules that a program uses could be set at the start, by compiler options (or the fqnall trick). This would avoid the name issues mentioned by pragma and Don (the "class std {...}") as well as allow an IDE to show completion for the available modules&packages.
> 
> Well, you can do this already with a
> ----
> module usingphobos;
> public import stdio = std.stdio;
> public import string = std.string;
> (etc)
> 
> 
> ----
> import usingphobos;
> 
> void main()
> {
>     stdio.writefln("Yes it works!");
> }
> ----
> All it takes is a single import at the top of each file.
> 

I know, that's what I call the fqnall trick. :)
(news://news.digitalmars.com:119/e8r8tt$10cf$3@digitaldaemon.com)

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D