> Hauke Duden wrote:
>
> > [Snip]
>
>
> > So IMHO "import" should mean "private import" and the other recursive import should be called "public import".
> >
> > This may seem like a minor issue, but I predict that newbies will use the plain "import" until they first stumble upon the dependency mess I described above. Then they have to change all their code to correct this issue, which can be frustrating. Since they usually want "private import", this can very easily be prevented by using the reasonable default.
> >
> > And if the newbie by any chance does not want private import, then at least the code will fail to compile right from the beginning and the programmer can read up on the import statements BEFORE he writes thousands of lines of code. If public import is the default, then the code might first compile well, but later cease to do so. Nothing is worse than making some small changes to a library and then discovering that lots of your application code doesn't compile anymore!
> >
> > Hauke
> >
> (With no particular preference in mind) Of course another way would be to have both explicit private and public.

Even better! Let's do that. Most implicit things are a specious convenience ... apart from implicit template instantiation, of course <G>

"Charles Sanders" <sanders-consulting@comcast.net> a écrit dans le message news: bo67jl$1rhu$1@digitaldaemon.com...

> Try to stay away from "shoulds" "this is the way it should be done" please it comes accross badly.

Excuse me, english is not my mother language thus it's sometime hard to transcibe intentions in words. I am really sorry if I offended anyone. Please replace "should"s by "may"s or anything implying modesty because I dont wanna claim anything, just suggest.

Regards.

-- Nicolas Repiquet

Hauke Duden wrote:
> Nicolas Repiquet wrote:
> 
>> D's import taste too much like #include :
...
> D does have "private import", which is exactly what you want. If file a contains a "private import b;" statement, then importing a will not automatically import b.
> 
> BUT I think that this should be the default. The only real application I see for the current default public import is when you want to have some sort of collector module that can be used to import a whole bunch of other modules at once. But since one usually imports a module to use it in the current module, this should almost always be a private import. Otherwise the code can quickly become a dependency mess, where one module fails to compile when an import statement in another module is changed.
> 
> So IMHO "import" should mean "private import" and the other recursive import should be called "public import".

This is my preference as well.  It doesn't seem particularly "safe" to use the powerful public import (I ran into a lot of problems with conflicting imports before "private import" was available), so it'd help to emphasize the danger by requiring an explicit "public import".  I think the default syntax should be less tricky for the novice programmer.

Justin

> 
> This may seem like a minor issue, but I predict that newbies will use the plain "import" until they first stumble upon the dependency mess I described above. Then they have to change all their code to correct this issue, which can be frustrating. Since they usually want "private import", this can very easily be prevented by using the reasonable default.
> 
> And if the newbie by any chance does not want private import, then at least the code will fail to compile right from the beginning and the programmer can read up on the import statements BEFORE he writes thousands of lines of code. If public import is the default, then the code might first compile well, but later cease to do so. Nothing is worse than making some small changes to a library and then discovering that lots of your application code doesn't compile anymore!
> 
> Hauke
> 

It didn't worry me; this is a robust bunch of people. :)

Having said that, I guess Charles' advice is useful in a general way. There are a lot less friendly newsgroups

"Nicolas Repiquet" <deadcow-remove-this@free.fr> wrote in message news:bo6s0q$2ou4$1@digitaldaemon.com...
>
> "Charles Sanders" <sanders-consulting@comcast.net> a écrit dans le message news: bo67jl$1rhu$1@digitaldaemon.com...
>
> > Try to stay away from "shoulds" "this is the way it should be done"
please
> > it comes accross badly.
>
> Excuse me, english is not my mother language thus it's sometime hard to transcibe intentions in words. I am really sorry if I offended anyone. Please replace "should"s by "may"s or anything implying modesty because I dont wanna claim anything, just suggest.
>
> Regards.
>
> -- Nicolas Repiquet
>
>
>

In fact, I favor the Python way here.

Case 1:
    import foo
    foo.bar()     # Explicitly qualify the module here

Case 2:
    from foo import bar # Only interested in bar()
    bar()    #No qualification needed

Case 3:
    from foo import * # Pull everything in foo into current scope
    bar()
    spam()

I don't know whether there are efficiency gains to be derived from limiting
the amount of stuff actually imported from
a module. In Case 1, it is a little more typing - but the advantages far
outweigh the small inconvenience.

import mod1
import mod2

mod1.foo()
mod2.foo() # No name conflicts here

I guess this is easier for the compiler as well as the programmer. This approach minimizes name collisions, should improve compile times, and generally improve robustness.

This is not meant to be yet another "implement-my-favorite-language-feature-in-d" suggestion. Just something I thought was worth emulating and found nearly foolproof.

Cheers,
Sarat



"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:bo68eo$1sl7$1@digitaldaemon.com...
> Nicolas Repiquet wrote:
> > D's import taste too much like #include :
> > <file a.d>
> >
> > module a;
> >
> > import b;
> >
> > doSomethingA() {}
> >
> > <file b.d>
> >
> > module b;
> >
> > doSomethingB() {}
> >
> > <file main.d>
> >
> > import a;
> >
> > void main() {
> >     doSomethingA();
> >     doSomethingB();
> > }
> >
> > Sad but true : the code above works perfectly =)
> >
> > "import" should be interpreted as "use" : importing 'a' dont
automagicaly
> > import 'b'. It's the java way for import. So main.d must be rewrote as :
>
> I agree completely!
>
> I was going to write a post on this topic just when I read yours ;).
>
> D does have "private import", which is exactly what you want. If file a contains a "private import b;" statement, then importing a will not automatically import b.
>
> BUT I think that this should be the default. The only real application I see for the current default public import is when you want to have some sort of collector module that can be used to import a whole bunch of other modules at once. But since one usually imports a module to use it in the current module, this should almost always be a private import. Otherwise the code can quickly become a dependency mess, where one module fails to compile when an import statement in another module is changed.
>
> So IMHO "import" should mean "private import" and the other recursive import should be called "public import".
>
> This may seem like a minor issue, but I predict that newbies will use the plain "import" until they first stumble upon the dependency mess I described above. Then they have to change all their code to correct this issue, which can be frustrating. Since they usually want "private import", this can very easily be prevented by using the reasonable
default.
>
> And if the newbie by any chance does not want private import, then at least the code will fail to compile right from the beginning and the programmer can read up on the import statements BEFORE he writes thousands of lines of code. If public import is the default, then the code might first compile well, but later cease to do so. Nothing is worse than making some small changes to a library and then discovering that lots of your application code doesn't compile anymore!
>
> Hauke
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.534 / Virus Database: 329 - Release Date: 10/31/2003

Yea sorry I was in a bad mood that morning :/.

C

"Nicolas Repiquet" <deadcow-remove-this@free.fr> wrote in message news:bo6s0q$2ou4$1@digitaldaemon.com...
>
> "Charles Sanders" <sanders-consulting@comcast.net> a écrit dans le message news: bo67jl$1rhu$1@digitaldaemon.com...
>
> > Try to stay away from "shoulds" "this is the way it should be done"
please
> > it comes accross badly.
>
> Excuse me, english is not my mother language thus it's sometime hard to transcibe intentions in words. I am really sorry if I offended anyone. Please replace "should"s by "may"s or anything implying modesty because I dont wanna claim anything, just suggest.
>
> Regards.
>
> -- Nicolas Repiquet
>
>
>

Nicolas answer also stands for me...
(I am in the same situation, even worse...)
So, sorry for offences...


In article <boa41n$1a56$1@digitaldaemon.com>, Charles Sanders says...
>
>Yea sorry I was in a bad mood that morning :/.
>
>C
>
>"Nicolas Repiquet" <deadcow-remove-this@free.fr> wrote in message news:bo6s0q$2ou4$1@digitaldaemon.com...
>>
>> "Charles Sanders" <sanders-consulting@comcast.net> a écrit dans le message news: bo67jl$1rhu$1@digitaldaemon.com...
>>
>> > Try to stay away from "shoulds" "this is the way it should be done"
>please
>> > it comes accross badly.
>>
>> Excuse me, english is not my mother language thus it's sometime hard to transcibe intentions in words. I am really sorry if I offended anyone. Please replace "should"s by "may"s or anything implying modesty because I dont wanna claim anything, just suggest.
>>
>> Regards.
>>
>> -- Nicolas Repiquet
>>
>>
>>
>
>

>>
>(With no particular preference in mind) Of course another way would be to have both explicit private and public.

For now we could add this to a list of suggested design/coding best practices methods for D.

Is there such a thing now? The WIKI site?

p.s.
DON'T put curly brace placement and other such stuff in the design/coding best
practices.

Mark T wrote:

>>(With no particular preference in mind) Of course another way would be to have both explicit private and public.
> 
> 
> For now we could add this to a list of suggested design/coding best practices
> methods for D.
> 
> Is there such a thing now? The WIKI site?
> 
> p.s.
> DON'T put curly brace placement and other such stuff in the design/coding best
> practices. 
> 
> 
There is such a page now (I started it since I know sometimes a blank page is stymieing)...

http://www.wikiservice.at/d/wiki.cgi?BestPractices

Anyone can edit it, so edit away.


Justin