www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How about Go's... error on unused imports?

reply Leandro Lucarella <llucax gmail.com> writes:
I'm sorry to bring up another "How about Go's ..." topic, but I think this
feature is very in sync with D and it should be really easy to implement.

Go issues an error if you have an import that's never used, to avoid
unnecessary dependencies.

Do you see any reasons not to do that? I think it happens very often to
stop using some import and never notice it.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
There is no pain you are receding
A distant ship, smoke on the horizon.
You are only coming through in waves.
Your lips move but I can't hear what you're saying.
Nov 12 2009
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thu, Nov 12, 2009 at 11:12:49PM -0300, Leandro Lucarella wrote:
 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.

I'll often import std.stdio when doing printf/writefln debugging. It'd be really annoying if the compiler threw an error when I comment out that writefln temporarily. -- Adam D. Ruppe http://arsdnet.net
Nov 12 2009
parent reply Justin Johansson <no spam.com> writes:
Adam D. Ruppe Wrote:

 On Thu, Nov 12, 2009 at 11:12:49PM -0300, Leandro Lucarella wrote:
 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.

I'll often import std.stdio when doing printf/writefln debugging. It'd be really annoying if the compiler threw an error when I comment out that writefln temporarily.

Uhmm, definitely should be a warning, not an error.
Nov 12 2009
parent reply Justin Johansson <no spam.com> writes:
Leandro Lucarella Wrote:

 Justin Johansson, el 12 de noviembre a las 21:40 me escribiste:
 Adam D. Ruppe Wrote:
 
 On Thu, Nov 12, 2009 at 11:12:49PM -0300, Leandro Lucarella wrote:
 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.

I'll often import std.stdio when doing printf/writefln debugging. It'd be really annoying if the compiler threw an error when I comment out that writefln temporarily.

Uhmm, definitely should be a warning, not an error.

I agree, but you know what's the D policy about warnings :-/

No, sorry I am not informed on D's policy about warnings; should I ask on D.learn?
Nov 12 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Justin Johansson" <no spam.com> wrote in message 
news:hdiliv$2ure$1 digitalmars.com...
 Leandro Lucarella Wrote:

 Justin Johansson, el 12 de noviembre a las 21:40 me escribiste:
 Adam D. Ruppe Wrote:

 On Thu, Nov 12, 2009 at 11:12:49PM -0300, Leandro Lucarella wrote:
 Do you see any reasons not to do that? I think it happens very 
 often to
 stop using some import and never notice it.

I'll often import std.stdio when doing printf/writefln debugging. It'd be really annoying if the compiler threw an error when I comment out that writefln temporarily.

Uhmm, definitely should be a warning, not an error.

I agree, but you know what's the D policy about warnings :-/

No, sorry I am not informed on D's policy about warnings; should I ask on D.learn?

Hee hee hee, this is getting quite interesting :)
Nov 12 2009
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Justin,

 Leandro Lucarella Wrote:
 
 Justin Johansson, el 12 de noviembre a las 21:40 me escribiste:
 
 Adam D. Ruppe Wrote:
 
 On Thu, Nov 12, 2009 at 11:12:49PM -0300, Leandro Lucarella wrote:
 
 Do you see any reasons not to do that? I think it happens very
 often to stop using some import and never notice it.
 

It'd be really annoying if the compiler threw an error when I comment out that writefln temporarily.



on D.learn?

If you turn on warnings, they act as errors (no object file is generated)
Nov 12 2009
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Justin Johansson wrote:

 No, sorry I am not informed on D's policy about warnings

Exactly. Ever wondered why that is? The policy is: there are no warnings.
Nov 13 2009
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Bill Baxter wrote:

 On Fri, Nov 13, 2009 at 10:28 AM, Lutger <lutger.blijdestijn gmail.com>
 wrote:
 Justin Johansson wrote:

 No, sorry I am not informed on D's policy about warnings

Exactly. Ever wondered why that is? The policy is: there are no warnings.

Probably more clear to say "all warnings are treated as errors." --bb

Note there is no way to treat warnings as warnings, making those 'warnings' just errors that can be turned on or off. Since there are no warnings to begin with, there are no warnings to treat as errors. I think that better reflects the idea that according to Walter, the concept of a compiler warning is inherently broken and thus rejected. Your code either compiles or not, which goes against the idea of what warnings are.
Nov 13 2009
parent Lutger <lutger.blijdestijn gmail.com> writes:
Bill Baxter wrote:

 On Fri, Nov 13, 2009 at 4:29 PM, Lutger <lutger.blijdestijn gmail.com>
 wrote:
 Bill Baxter wrote:

 On Fri, Nov 13, 2009 at 10:28 AM, Lutger <lutger.blijdestijn gmail.com>
 wrote:
 Justin Johansson wrote:

 No, sorry I am not informed on D's policy about warnings

Exactly. Ever wondered why that is? The policy is: there are no warnings.

Probably more clear to say "all warnings are treated as errors." --bb

Note there is no way to treat warnings as warnings, making those 'warnings' just errors that can be turned on or off. Since there are no warnings to begin with, there are no warnings to treat as errors. I think that better reflects the idea that according to Walter, the concept of a compiler warning is inherently broken and thus rejected. Your code either compiles or not, which goes against the idea of what warnings are.

We're just splitting hairs here, but the nuance I got from "there are no warnings" is that there are no checks ever performed of the type most compilers call warnings. That's not true. It does perform those kinds of checks with the -w flag, it just causes the compilation to fail when such things are found.

Ah I see, that's not what I meant.
 
 So all I'm sayin' is that if you're trying to actually be helpful,
 then a better explanation is "all warnings are treated as errors".  If
 just want to make a political point, maybe your way is better.
 
 --bb

Perhaps you're right, I might be too indoctrinated.
Nov 13 2009
prev sibling next sibling parent reply Justin Johansson <no spam.com> writes:
Leandro Lucarella Wrote:

 I'm sorry to bring up another "How about Go's ..." topic, but I think this
 feature is very in sync with D and it should be really easy to implement.
 
 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.
 
 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.
 

In my opinion, this is a very good idea. I continually remove imports when I think they might not be used anymore. Sometimes I'm right and sometimes I'm wrong and the compiler tells me accordingly. It would be nice to have a warning for unused imports to save the tedium of a redo. From a code understanding point of view it helps not to be obfusticated by unused imports. beers Leandro for picking this up, Justin
Nov 12 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Justin Johansson wrote:
 Leandro Lucarella Wrote:
 
 I'm sorry to bring up another "How about Go's ..." topic, but I think this
 feature is very in sync with D and it should be really easy to implement.

 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.

 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.

In my opinion, this is a very good idea. I continually remove imports when I think they might not be used anymore. Sometimes I'm right and sometimes I'm wrong and the compiler tells me accordingly. It would be nice to have a warning for unused imports to save the tedium of a redo. From a code understanding point of view it helps not to be obfusticated by unused imports. beers Leandro for picking this up, Justin

I think this is an environment issue. I like Eclipse's approach. Java unnecessary imports are underlined with a wavy red line. Andrei
Nov 12 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 I think this is an environment issue. I like Eclipse's approach. Java 
 unnecessary imports are underlined with a wavy red line.

I agree. I would find it very annoying to have to remove unused imports to get it to compiler. First off, I tend to have "all" imports that import everything. Secondly, what if I version out some code, wouldn't want to version the import too.
Nov 12 2009
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Leandro Lucarella wrote:
 Walter Bright, el 12 de noviembre a las 19:35 me escribiste:
 Andrei Alexandrescu wrote:
 I think this is an environment issue. I like Eclipse's approach.
 Java unnecessary imports are underlined with a wavy red line.

imports to get it to compiler. First off, I tend to have "all" imports that import everything.

That's odd, first you say you think D would be a failure if it needs an IDE and now you say that the only way to avoid unnecessary dependencies you should rely on an IDE =) I really think this should be a compiler feature. Make it a warning then (and while you are at it, make it a *real* warning, not a warning-error).
 Secondly, what if I version out some code, wouldn't want to version the
 import too.

Why?

Given the way DMD currently works, such a feature could only say this import is unused in this version configuration. There's no way to know if the import is used in a different version configuration, short of running compiles for every possible one.
Nov 13 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el 12 de noviembre a las 19:35 me escribiste:
 Andrei Alexandrescu wrote:
 I think this is an environment issue. I like Eclipse's approach.
 Java unnecessary imports are underlined with a wavy red line.

imports to get it to compiler. First off, I tend to have "all" imports that import everything.

That's odd, first you say you think D would be a failure if it needs an IDE and now you say that the only way to avoid unnecessary dependencies you should rely on an IDE =)

It's not a problem that needs fixing. It's not a bug, it's a stylistic issue. IDEs are good for that.
 I really think this should be a compiler feature. Make it a warning then
 (and while you are at it, make it a *real* warning, not a warning-error).
 
 Secondly, what if I version out some code, wouldn't want to version the
 import too.

Why?

Because I often block out and unblock out code during development. Having to go up and dink with the imports too would be quite annoying. At some point, adding too much of this nagging stuff into a language will drive people away.
Nov 16 2009
parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:hdr7mp$1ei2$1 digitalmars.com...
 Leandro Lucarella wrote:
 Walter Bright, el 12 de noviembre a las 19:35 me escribiste:
 Andrei Alexandrescu wrote:
 I think this is an environment issue. I like Eclipse's approach.
 Java unnecessary imports are underlined with a wavy red line.

imports to get it to compiler. First off, I tend to have "all" imports that import everything.

That's odd, first you say you think D would be a failure if it needs an IDE and now you say that the only way to avoid unnecessary dependencies you should rely on an IDE =)

It's not a problem that needs fixing. It's not a bug, it's a stylistic issue. IDEs are good for that.
 I really think this should be a compiler feature. Make it a warning then
 (and while you are at it, make it a *real* warning, not a warning-error).

 Secondly, what if I version out some code, wouldn't want to version the
 import too.

Why?

Because I often block out and unblock out code during development. Having to go up and dink with the imports too would be quite annoying. At some point, adding too much of this nagging stuff into a language will drive people away.

The is why the general consensus in the thread is that it should be an optional notice by the compiler rather than an error. So you don't want to have to remove unused imports to get something to compile? Great. I fully agree. So how about having it as an optional diagnostic (as almost everyone on this thread has suggested)? It's pretty hard to imagine that causing anyone any trouble.
Nov 16 2009
prev sibling parent reply Justin Johansson <no spam.com> writes:
Andrei Alexandrescu Wrote:

 Justin Johansson wrote:
 Leandro Lucarella Wrote:
 
 I'm sorry to bring up another "How about Go's ..." topic, but I think this
 feature is very in sync with D and it should be really easy to implement.

 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.

 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.

In my opinion, this is a very good idea. I continually remove imports when I think they might not be used anymore. Sometimes I'm right and sometimes I'm wrong and the compiler tells me accordingly. It would be nice to have a warning for unused imports to save the tedium of a redo. From a code understanding point of view it helps not to be obfusticated by unused imports. beers Leandro for picking this up, Justin

I think this is an environment issue. I like Eclipse's approach. Java unnecessary imports are underlined with a wavy red line. Andrei

I don't like to engage in unnecessary debate but please consider: 1. the suggestion is for a warning message not an error (perhaps even enabled by a compiler switch or warning level), 2. by environment I presume you mean development system and/or editor. Sure Eclipse does okay with Java unused imports as you say. Now whist I use Eclipse with Descent plugin, relying on environment presupposes that environments support the feature. Descent currently does not; perhaps it will in the near future. It is fair conjecture though that widespead, mature support for D IDE-wise may well be sometime into the future. This is to say nothing for those that prefer to hack with command line tools and light-weight editors. So in summary, my humble opinion is that placing this responsibility onto the environment is both pie in the sky and passing the buck. Justin
Nov 12 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Justin Johansson" <no spam.com> wrote in message 
news:hdikl4$2rg7$1 digitalmars.com...
 Andrei Alexandrescu Wrote:
 I think this is an environment issue. I like Eclipse's approach. Java
 unnecessary imports are underlined with a wavy red line.


 Andrei

I don't like to engage in unnecessary debate but please consider: 1. the suggestion is for a warning message not an error (perhaps even enabled by a compiler switch or warning level), 2. by environment I presume you mean development system and/or editor. Sure Eclipse does okay with Java unused imports as you say. Now whist I use Eclipse with Descent plugin, relying on environment presupposes that environments support the feature. Descent currently does not; perhaps it will in the near future. It is fair conjecture though that widespead, mature support for D IDE-wise may well be sometime into the future. This is to say nothing for those that prefer to hack with command line tools and light-weight editors. So in summary, my humble opinion is that placing this responsibility onto the environment is both pie in the sky and passing the buck. Justin

*Your* humble opinion? You liar! That's my humble opinion too! ;) But yea, this is exactly the kind of thing that warnings (*true* warnings) are *supposed* to be for. Also, as far as Java goes, *everything* is an environment issue. Hell, I'm almost surprised they don't outlaw non-recursive functions, non-infinite loops, generics and sources-across-multiple-files from Java just so they could have Eclipse auto-generate that much more clutter and redundancy. Come to think of it...if I ever get a chance, I'm going to make a language just like that with a corresponding Eclipse plugin just to be an ass and make a point ;)
Nov 12 2009
parent reply Justin Johansson <no spam.com> writes:
Nick Sabalausky Wrote:

 
 "Justin Johansson" <no spam.com> wrote in message 
 news:hdikl4$2rg7$1 digitalmars.com...
 Andrei Alexandrescu Wrote:
 I think this is an environment issue. I like Eclipse's approach. Java
 unnecessary imports are underlined with a wavy red line.


 Andrei

I don't like to engage in unnecessary debate but please consider: 1. the suggestion is for a warning message not an error (perhaps even enabled by a compiler switch or warning level), 2. by environment I presume you mean development system and/or editor. Sure Eclipse does okay with Java unused imports as you say. Now whist I use Eclipse with Descent plugin, relying on environment presupposes that environments support the feature. Descent currently does not; perhaps it will in the near future. It is fair conjecture though that widespead, mature support for D IDE-wise may well be sometime into the future. This is to say nothing for those that prefer to hack with command line tools and light-weight editors. So in summary, my humble opinion is that placing this responsibility onto the environment is both pie in the sky and passing the buck. Justin

*Your* humble opinion? You liar! That's my humble opinion too! ;) But yea, this is exactly the kind of thing that warnings (*true* warnings) are *supposed* to be for. Also, as far as Java goes, *everything* is an environment issue. Hell, I'm almost surprised they don't outlaw non-recursive functions, non-infinite loops, generics and sources-across-multiple-files from Java just so they could have Eclipse auto-generate that much more clutter and redundancy. Come to think of it...if I ever get a chance, I'm going to make a language just like that with a corresponding Eclipse plugin just to be an ass and make a point ;)

I'll pay that one Nick!!! I admit that startled me at first when my lexical analyser scanned "liar" ahead of reading the rest of your smartarse comment :-)
Nov 12 2009
parent "Nick Sabalausky" <a a.a> writes:
"Justin Johansson" <no spam.com> wrote in message 
news:hdin02$332$1 digitalmars.com...
 Nick Sabalausky Wrote:

 "Justin Johansson" <no spam.com> wrote in message
 news:hdikl4$2rg7$1 digitalmars.com...
 Andrei Alexandrescu Wrote:
 I think this is an environment issue. I like Eclipse's approach. Java
 unnecessary imports are underlined with a wavy red line.


 Andrei

I don't like to engage in unnecessary debate but please consider: 1. the suggestion is for a warning message not an error (perhaps even enabled by a compiler switch or warning level), 2. by environment I presume you mean development system and/or editor. Sure Eclipse does okay with Java unused imports as you say. Now whist I use Eclipse with Descent plugin, relying on environment presupposes that environments support the feature. Descent currently does not; perhaps it will in the near future. It is fair conjecture though that widespead, mature support for D IDE-wise may well be sometime into the future. This is to say nothing for those that prefer to hack with command line tools and light-weight editors. So in summary, my humble opinion is that placing this responsibility onto the environment is both pie in the sky and passing the buck. Justin

*Your* humble opinion? You liar! That's my humble opinion too! ;) But yea, this is exactly the kind of thing that warnings (*true* warnings) are *supposed* to be for. Also, as far as Java goes, *everything* is an environment issue. Hell, I'm almost surprised they don't outlaw non-recursive functions, non-infinite loops, generics and sources-across-multiple-files from Java just so they could have Eclipse auto-generate that much more clutter and redundancy. Come to think of it...if I ever get a chance, I'm going to make a language just like that with a corresponding Eclipse plugin just to be an ass and make a point ;)

I'll pay that one Nick!!! I admit that startled me at first when my lexical analyser scanned "liar" ahead of reading the rest of your smartarse comment :-)

Heh, I'm in a real smarta(ss|rse) mood today. I don't know why. Maybe it's the alignment of the star^H^H^H^H read/write heads.
Nov 12 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Justin Johansson, el 12 de noviembre a las 21:40 me escribiste:
 Adam D. Ruppe Wrote:
 
 On Thu, Nov 12, 2009 at 11:12:49PM -0300, Leandro Lucarella wrote:
 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.

I'll often import std.stdio when doing printf/writefln debugging. It'd be really annoying if the compiler threw an error when I comment out that writefln temporarily.

Uhmm, definitely should be a warning, not an error.

I agree, but you know what's the D policy about warnings :-/ -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Es mas posible, que un elefante maneje un cero km a que un camello habite un departamento de un ambiente. -- Peperino Pómoro
Nov 12 2009
prev sibling next sibling parent reply "Phil Deets" <pjdeets2 gmail.com> writes:
On Thu, 12 Nov 2009 21:12:49 -0500, Leandro Lucarella <llucax gmail.com>  
wrote:

 I'm sorry to bring up another "How about Go's ..." topic, but I think  
 this
 feature is very in sync with D and it should be really easy to implement.

 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.

 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.

I don't think this should be an error normally. Maybe if dmd got an -analyze switch that preformed extra checks with static code analysis, this could be one of those checks. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Nov 12 2009
parent "Nick Sabalausky" <a a.a> writes:
"Phil Deets" <pjdeets2 gmail.com> wrote in message 
news:op.u3bfg4rz1py94j desktop.neo.rr.com...
 On Thu, 12 Nov 2009 21:12:49 -0500, Leandro Lucarella <llucax gmail.com> 
 wrote:

 I'm sorry to bring up another "How about Go's ..." topic, but I think 
 this
 feature is very in sync with D and it should be really easy to implement.

 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.

 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.

I don't think this should be an error normally. Maybe if dmd got n -analyze switch that preformed extra checks with static code analysis, this could be one of those checks.

At the risk of sounding like a broken record (do people outside the DJ scene still know what those are?), that's what warnings are [supposed to] be.
Nov 12 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:

 I'm sorry to bring up another "How about Go's ..." topic, but I think this
 feature is very in sync with D and it should be really easy to implement.
 
 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.

I think I'd like d compilers to have a switch (-wunused ?) that when present warns me for unused variables, functions, imports, classes, etc. This helps keep the code tidy and tight. Then later IDEs can use this output to underline what's unused. I use -Wall in C and I find it useful when it tells me that there are unused variables. Unused variables can be stuff that I need to use but I have forgotten to use, or stuff that I have used in an older version of the code and now are not used anymore, etc. Sometimes variables are not used because conditional compilation has disabled a part of the code that uses that variable. In this case I may want to move the variable definition inside the optionally compiled part of the code, this improves the code a little. In many situations I want to know if I have not used them. Bye, bearophile
Nov 13 2009
parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hdjhuu$10f9$1 digitalmars.com...
 Leandro Lucarella:

 I'm sorry to bring up another "How about Go's ..." topic, but I think 
 this
 feature is very in sync with D and it should be really easy to implement.

 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.

I think I'd like d compilers to have a switch (-wunused ?) that when present warns me for unused variables, functions, imports, classes, etc. This helps keep the code tidy and tight. Then later IDEs can use this output to underline what's unused. I use -Wall in C and I find it useful when it tells me that there are unused variables. Unused variables can be stuff that I need to use but I have forgotten to use, or stuff that I have used in an older version of the code and now are not used anymore, etc. Sometimes variables are not used because conditional compilation has disabled a part of the code that uses that variable. In this case I may want to move the variable definition inside the optionally compiled part of the code, this improves the code a little. In many situations I want to know if I have not used them. Bye, bearophile

Vote: http://d.puremagic.com/issues/show_bug.cgi?id=2197
Nov 13 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 12 de noviembre a las 19:35 me escribiste:
 Andrei Alexandrescu wrote:
I think this is an environment issue. I like Eclipse's approach.
Java unnecessary imports are underlined with a wavy red line.

I agree. I would find it very annoying to have to remove unused imports to get it to compiler. First off, I tend to have "all" imports that import everything.

That's odd, first you say you think D would be a failure if it needs an IDE and now you say that the only way to avoid unnecessary dependencies you should rely on an IDE =) I really think this should be a compiler feature. Make it a warning then (and while you are at it, make it a *real* warning, not a warning-error).
 Secondly, what if I version out some code, wouldn't want to version the
 import too.

Why? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Ingeniero Juanjo Charlante, Linux es como una mermelada?
Nov 13 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Ellery Newcomer, el 13 de noviembre a las 08:36 me escribiste:
 Secondly, what if I version out some code, wouldn't want to version the
 import too.

Why?

Given the way DMD currently works, such a feature could only say this import is unused in this version configuration. There's no way to know if the import is used in a different version configuration, short of running compiles for every possible one.

I know, my question was "why don't you want to put the import inside a version statement"? BTW, I just saw that you can use an import for which you don't use any symbols (for example, if you want the module initiazation to be executed), you just have to alias the import to the "blank" identifier (_): import _ "something"; I guess something like this can solve this issue too (if unused imports are errors/warnings). It's a valid use case too since D have module initialization too. And this got me thinking, that importing something you don't use might execute code you don't want to be executed (I think because of this, unused imports are not just an "environmental" problem). So I think that this can be a good feature for D too. Since D doesn't have a "blank" identifier, maybe void can be used as a special case (it's used for other special cases, like no initialization already, so): import void = something; It looks a little confusing though. But maybe someone can figure out an alternative syntax. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- El techo de mi cuarto lleno de cometas
Nov 13 2009
prev sibling next sibling parent reply Clay Smith <clay.smith.r gmail.com> writes:
Leandro Lucarella wrote:
 I'm sorry to bring up another "How about Go's ..." topic, but I think this
 feature is very in sync with D and it should be really easy to implement.
 
 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.
 
 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.
 

No, this is a job to be left to the IDE, not compiler.
Nov 13 2009
next sibling parent reply Clay Smith <clay.smith.r gmail.com> writes:
Bill Baxter wrote:
 On Fri, Nov 13, 2009 at 9:51 AM, Clay Smith <clay.smith.r gmail.com> wrote:
 Leandro Lucarella wrote:
 I'm sorry to bring up another "How about Go's ..." topic, but I think this
 feature is very in sync with D and it should be really easy to implement.

 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.

 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.


Well, just a small argument for the contrary, but you may be importing some module precisely for the purpose of getting its module constructors to run. For instance the module constructor may have a call like RegisterComponent(thisModule) in it. Think of a set of image format loaders that register themselves with the main ImageLoader module. Then you call ImageLoader.load(filename). Nowhere in your code do you care if it is a PNG or not. You only need to use the ImageLoader's API. Also there's public imports. And all.d type modules with nothing but pubilic imports. There's no way an IDE can know about those intents. So that argues that there should be a way in the language to indicate "i know it doesn't look like I'm using this, but I am". And if that's in the language then the compiler might as well do the checking, too. Ok, not a super strong argument... unless D changed to compile things the way Go does, rolling in all deps. How about that one from Go? Including all deps in an obj. Could D use the same trick to speed up compilation further? --bb

I'm not really understanding what you are saying, but I see no need for the compiler to error on unused import. If anything, the compiler can just ignore it, or have a flag to find unused imports. I would like my all.d files to not give errors :o
Nov 13 2009
next sibling parent reply Clay Smith <clay.smith.r gmail.com> writes:
Clay Smith wrote:
 Bill Baxter wrote:
 On Fri, Nov 13, 2009 at 9:51 AM, Clay Smith <clay.smith.r gmail.com> 
 wrote:
 Leandro Lucarella wrote:
 I'm sorry to bring up another "How about Go's ..." topic, but I 
 think this
 feature is very in sync with D and it should be really easy to 
 implement.

 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.

 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.


Well, just a small argument for the contrary, but you may be importing some module precisely for the purpose of getting its module constructors to run. For instance the module constructor may have a call like RegisterComponent(thisModule) in it. Think of a set of image format loaders that register themselves with the main ImageLoader module. Then you call ImageLoader.load(filename). Nowhere in your code do you care if it is a PNG or not. You only need to use the ImageLoader's API. Also there's public imports. And all.d type modules with nothing but pubilic imports. There's no way an IDE can know about those intents. So that argues that there should be a way in the language to indicate "i know it doesn't look like I'm using this, but I am". And if that's in the language then the compiler might as well do the checking, too. Ok, not a super strong argument... unless D changed to compile things the way Go does, rolling in all deps. How about that one from Go? Including all deps in an obj. Could D use the same trick to speed up compilation further? --bb

I'm not really understanding what you are saying, but I see no need for the compiler to error on unused import. If anything, the compiler can just ignore it, or have a flag to find unused imports. I would like my all.d files to not give errors :o

Plus copy/paste imports from other modules, without compile error :o
Nov 13 2009
parent Clay Smith <clay.smith.r gmail.com> writes:
Bill Baxter wrote:
 On Fri, Nov 13, 2009 at 10:23 AM, Clay Smith <clay.smith.r gmail.com> wrote:
 Clay Smith wrote:
 Bill Baxter wrote:
 On Fri, Nov 13, 2009 at 9:51 AM, Clay Smith <clay.smith.r gmail.com>
 wrote:
 Leandro Lucarella wrote:
 I'm sorry to bring up another "How about Go's ..." topic, but I think
 this
 feature is very in sync with D and it should be really easy to
 implement.

 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.

 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.


some module precisely for the purpose of getting its module constructors to run. For instance the module constructor may have a call like RegisterComponent(thisModule) in it. Think of a set of image format loaders that register themselves with the main ImageLoader module. Then you call ImageLoader.load(filename). Nowhere in your code do you care if it is a PNG or not. You only need to use the ImageLoader's API. Also there's public imports. And all.d type modules with nothing but pubilic imports. There's no way an IDE can know about those intents. So that argues that there should be a way in the language to indicate "i know it doesn't look like I'm using this, but I am". And if that's in the language then the compiler might as well do the checking, too. Ok, not a super strong argument... unless D changed to compile things the way Go does, rolling in all deps. How about that one from Go? Including all deps in an obj. Could D use the same trick to speed up compilation further? --bb



It's not that complicated. Maybe try reading it again. And forget about the example of why you might want to import something without using it, just trust that there are legit cases where you might want to.

ok
 
 but I see no need for
 the compiler to error on unused import. If anything, the compiler can just
 ignore it, or have a flag to find unused imports. I would like my all.d
 files to not give errors :o


Actually, I agree that the compiler should not error unused *public* imports. That really would not make any sense.

True
 
 Plus copy/paste imports from other modules, without compile error :o

Why do you want to paste in a bunch of unused imports? Wouldn't you like to know which ones you use and which you don't, and trim the fat? --bb

If I want to save time, and I'm developing a module similar to an existing one, copying/pasting imports is 90% accurate and saves me time, which is invaluable.
Nov 13 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Clay Smith:

I would like my all.d files to not give errors :o<

"all.d" files are a hack used to patch one of the minor holes of the current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *; Every part of a language needs to be designed with care. Approximate designs with several holes aren't enough. Bye, bearophile
Nov 13 2009
next sibling parent reply Clay Smith <clay.smith.r gmail.com> writes:
bearophile wrote:
 Clay Smith:
 
 I would like my all.d files to not give errors :o<

"all.d" files are a hack used to patch one of the minor holes of the current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *; Every part of a language needs to be designed with care. Approximate designs with several holes aren't enough. Bye, bearophile

That would be a nice feature.
Nov 13 2009
next sibling parent Clay Smith <clay.smith.r gmail.com> writes:
Bill Baxter wrote:
 On Fri, Nov 13, 2009 at 11:15 AM, Clay Smith <clay.smith.r gmail.com> wrote:
 bearophile wrote:
 Clay Smith:

 I would like my all.d files to not give errors :o<

current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *; Every part of a language needs to be designed with care. Approximate designs with several holes aren't enough. Bye, bearophile


It would be a convenient feature, but in both Java and Python where they have this feature, its use is frowned upon. --bb

I don't understand why its frowned upon, if you really want to see what you are importing then look at the folder where the import is coming from.
Nov 13 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 It would be a convenient feature, but in both Java and Python where
 they have this feature, its use is frowned upon.

I agree, but: - It may be handy in small script-like programs. - It has the advantage of removing the need of the "all.d" modules that are hackish. - Once you use it such * syntax can be recognized by automatic tools that test for code quality (like an IDE, or like this single Python module used by Google to spot troubles in C++ code: http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py ). So they may complain :-) Bye, bearophile
Nov 13 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

but in both Java and Python where they have this feature, its use is frowned
upon.<

You are right, we can live without this small anti-feature. But I want so see some of the holes of the D module system fixed. Bye, bearophile
Nov 13 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 On Fri, Nov 13, 2009 at 11:15 AM, Clay Smith <clay.smith.r gmail.com> wrote:
 bearophile wrote:
 Clay Smith:

 I would like my all.d files to not give errors :o<

current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *; Every part of a language needs to be designed with care. Approximate designs with several holes aren't enough. Bye, bearophile


It would be a convenient feature, but in both Java and Python where they have this feature, its use is frowned upon. --bb

Yes. Even Eclipse protests about that and suggests you replace the umbrella import with a detailed list. Andrei
Nov 13 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hdkavm$1b0k$1 digitalmars.com...
 Clay Smith:

I would like my all.d files to not give errors :o<

"all.d" files are a hack used to patch one of the minor holes of the current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *; Every part of a language needs to be designed with care. Approximate designs with several holes aren't enough.

I used to think so, but I'm not so sure anymore. In my Goldie project, one of the modules ("goldie.file") is something with a whole lot of types and details about loading a .cgt file. In the vast majority of use-cases, the Goldie library user has no reason to use any of those directly, so as useful as "goldie.all" is, it would be pointless for me to include that "goldie.file" in "goldie.all", which is exactly what "goldie.*" would do automatically if it existed. Now, certainly, I could just mark everything in "goldie.file" as private, but I do want people to be able to import and use it directly if they want to (Ex, if they want to use Goldie as a springboard for their own .cgt-file handling routines). Plus, I'll often have renamed and deliberately unused source files in the same directory as "real" modules, and I wouldn't want them automatically grabbed by ".*". I suppose I could change their extension, but then the editor would get confused, and I'd have to work around that, etc...
Nov 13 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:hdklbg$2p2f$1 digitalmars.com...
 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:hdkavm$1b0k$1 digitalmars.com...
 Clay Smith:

I would like my all.d files to not give errors :o<

"all.d" files are a hack used to patch one of the minor holes of the current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *; Every part of a language needs to be designed with care. Approximate designs with several holes aren't enough.

I used to think so, but I'm not so sure anymore. In my Goldie project, one of the modules ("goldie.file") is something with a whole lot of types and details about loading a .cgt file. In the vast majority of use-cases, the Goldie library user has no reason to use any of those directly, so as useful as "goldie.all" is, it would be pointless for me to include that "goldie.file" in "goldie.all", which is exactly what "goldie.*" would do automatically if it existed. Now, certainly, I could just mark everything in "goldie.file" as private, but I do want people to be able to import and use it directly if they want to (Ex, if they want to use Goldie as a springboard for their own .cgt-file handling routines). Plus, I'll often have renamed and deliberately unused source files in the same directory as "real" modules, and I wouldn't want them automatically grabbed by ".*". I suppose I could change their extension, but then the editor would get confused, and I'd have to work around that, etc...

Another Goldie-derived example of ".all" being more useful than ".*": I'm building a tool that generates a statically-compiled and linked D source version of a grammar (normally they're loaded at runtime from a file). Unless I change my mind, I intend for these to be used with "import somelang = myapp.staticlangs.somelang.all", so that multiple static langauges can be used together (Ie, "d.Token", "haxe.Token", "js.Token", whatever). I originally had the generation tool give unique names to each type (Ie, "Token_haxe", "Token_js", etc), but I'm thinking now the renamed import approach is probably more appropriate and less hack-ish, and comes with more built-in flexibility. But anyway, suppose someone has a project with multiple languages like this (ex "myapp.staticlangs.haxe.all" and "myapp.staticlangs.js.all", and maybe a couple others). If they tried an "import myapp.staticlangs.*" approach, that just wouldn't work, because they're designed to be used as renamed imports. But they could easily create a "myapp.staticlangs.all" (or hell, I could even generate one) that would automatically do the correct renamed imports. Anyway, just another thing that ".*" importing can't really handle.
Nov 13 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:
 I used to think so, but I'm not so sure anymore.

It's the same for me. I can live without the *, as I can live without D typedef. There are other changes/fixed that I want for the module system still. Bye, bearophile
Nov 13 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Nick Sabalausky:
 I used to think so, but I'm not so sure anymore.

It's the same for me. I can live without the *, as I can live without D typedef. There are other changes/fixed that I want for the module system still.

Are they in bugzilla? bugzilla: That stone will be eventually turned and looked under. You will bask in the glorious sun of well-deserved recognition. newsgroup: None of that good stuff. Andrei
Nov 13 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:

 and "marked" them with [module]

Thank you for your work. This is good: http://d.puremagic.com/issues/show_bug.cgi?id=3503 Once all those things are fixed, the module system will start to look OK regarding *modules*, but I think the semantics of the packages and their usage will need some tuning still. See also the super-packages of Java: http://www.javabeat.net/articles/120-new-features-in-java-70-part-1-4.html
I didn't included cyclic/forward references bugs though:<

You may add them too. Bye, bearophile
Nov 14 2009
parent bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 I think this word "may" does not mean quite what you think it does.
 What you wrote there basically means "You have my permission to add them, too",
 like a teacher might say to a student.

You are right, and that was not my purpose...
 If it can be interpreted as
 giving permission, it will be.   "Might" doesn't have that ambiguity.

I'll keep this in mind.
 In the above situation, I would say either "It might be a good idea to
 add them too".  Or just ask directly "Could you please add them, too?"

I hope this too is acceptable: "You might add those too" :-) Thank you very much for your English lessons, bear(ish) hugs, bearophile
Nov 14 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Leandro Lucarella:
 http://d.puremagic.com/issues/buglist.cgi?quicksearch=[module]

I have forgotten a small thing: http://d.puremagic.com/issues/show_bug.cgi?id=3504 That syntax must not import the "foo" module name too. So inside "foo" I may have a name "foo" too and no problems happen. Bye, bearophile
Nov 14 2009
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 14/11/2009 00:28, bearophile wrote:
 Nick Sabalausky:
 I used to think so, but I'm not so sure anymore.

It's the same for me. I can live without the *, as I can live without D typedef. There are other changes/fixed that I want for the module system still. Bye, bearophile

once upon a time there was a suggestion to have a special file that would define the public API of a package. e.g. myPackage a.d b.d ... this.d // special file that defines the public imports private.d // should not be imported by a "*" import then, the user can import myPackage.* and that would search for this.d in the directory and use its contents instead of importing all d files in the directory.
Nov 14 2009
parent reply KennyTM~ <kennytm gmail.com> writes:
On Nov 14, 09 16:32, Yigal Chripun wrote:
 On 14/11/2009 00:28, bearophile wrote:
 Nick Sabalausky:
 I used to think so, but I'm not so sure anymore.

It's the same for me. I can live without the *, as I can live without D typedef. There are other changes/fixed that I want for the module system still. Bye, bearophile

once upon a time there was a suggestion to have a special file that would define the public API of a package. e.g. myPackage a.d b.d ... this.d // special file that defines the public imports private.d // should not be imported by a "*" import then, the user can import myPackage.* and that would search for this.d in the directory and use its contents instead of importing all d files in the directory.

How is it different from using an all.d and import myPackage.all ?
Nov 14 2009
parent KennyTM~ <kennytm gmail.com> writes:
On Nov 15, 09 04:38, Leandro Lucarella wrote:
 KennyTM~, el 15 de noviembre a las 03:17 me escribiste:
 once upon a time there was a suggestion to have a special file that
 would define the public API of a package.

 e.g.

 myPackage
 a.d
 b.d
 ...
 this.d // special file that defines the public imports
 private.d // should not be imported by a "*" import

 then, the user can import myPackage.* and that would search for this.d
 in the directory and use its contents instead of importing all d files
 in the directory.

How is it different from using an all.d and import myPackage.all ?

It will just make importing shorter (and it will encourage people to use the "all" trick as it's part of the language and not just a convention).

I think the problem isn't it's shorter (use could use myPackage/a.d), but not enough important libraries are using this trick. For C/Obj-C on Mac OS X programming, to import a whole framework you always use #import <frameworkName/frameworkName.h>. This is just a convention, but everyone is using this, because it's a standardized convention. Imagine if there are std.all & tango.all.
Nov 15 2009
prev sibling parent Justin Johansson <no spam.com> writes:
 Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
 ----------------------------------------------------------------------
 GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
 ----------------------------------------------------------------------
 Long you live and high you fly
 And smiles you'll give and tears you'll cry
 And all you touch and all you see
 Is all your life will ever be.

Breathe, breathe in the air.
Nov 13 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Clay Smith:
 
 I would like my all.d files to not give errors :o<

"all.d" files are a hack used to patch one of the minor holes of the current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *;

Sorry, I think that * approach is far worse as you never can be sure what it is picking up.
Nov 13 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el 13 de noviembre a las 18:17 me escribiste:
 bearophile wrote:
 Clay Smith:

 I would like my all.d files to not give errors :o<

current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *;

what it is picking up.

!? import std.foo: *; is the current behavior for import std.foo;!

I thought you were asking for all .d files in the directory foo?
Nov 13 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Does this makes more sense?

Yes.
Nov 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el 14 de noviembre a las 10:36 me escribiste:
 Leandro Lucarella wrote:
 Does this makes more sense?


It would be pushing to much to ask if you're willing to give it a serious thought then? =)

I understand it (I think), but I'm not as keen on it as you are <g>. Consider that D has function hijacking protection (I think this is unique to D) so that inadvertent overloading by the same names in different imports is virtually eliminated. So I think the marginal benefit of the proposed changes is small.
Nov 14 2009
parent Don <nospam nospam.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el 14 de noviembre a las 14:59 me escribiste:
 Leandro Lucarella wrote:
 Walter Bright, el 14 de noviembre a las 10:36 me escribiste:
 Leandro Lucarella wrote:
 Does this makes more sense?


thought then? =)

Consider that D has function hijacking protection (I think this is unique to D) so that inadvertent overloading by the same names in different imports is virtually eliminated. So I think the marginal benefit of the proposed changes is small.

I can see that it would be too much trouble for too little gain (from you POV, I still think that readability is key for code-review, which I consider key for high-quality code).

It seems to me that it is a code beautifier proposal. When your code is completely working, you many run some kind of 'beautify' step. There are many other beautifier processes that could be run. They improve the productivity of the maintenance guys but I think it would be a severe nuisance to be required to use them continuously during development.
Nov 14 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Bill Baxter, el 14 de noviembre a las 06:47 me escribiste:
 On Sat, Nov 14, 2009 at 5:17 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Leandro Lucarella:

 and "marked" them with [module]

Thank you for your work. This is good: http://d.puremagic.com/issues/show_bug.cgi?id=3503 Once all those things are fixed, the module system will start to look OK regarding *modules*, but I think the semantics of the packages and their usage will need some tuning still.

I used to be for such a change, but I'm not sure anymore that it's a good idea for D. See the comment I added to the report. One thing that I'd like would be a DRY way to use the leaf name of a module. Often I end up writing things like: import MyModule = foo.bar.MyModule; Maybe something like this could be allowed to mean the same thing: import (foo.bar.)MyModule; I think this has been brought up before, but I don't recall any good suggestions.

As I said in the bug report, see bug 3505 too ;) http://d.puremagic.com/issues/show_bug.cgi?id=3505 I reported 3 separated bugs because they are orthogonal features, but they make more sense if all are implemented at the same time: http://d.puremagic.com/issues/show_bug.cgi?id=3503 http://d.puremagic.com/issues/show_bug.cgi?id=3504 http://d.puremagic.com/issues/show_bug.cgi?id=3505 -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- El techo de mi cuarto lleno de planetas Y mi mente es un planeta más Donde vivo yo y nadie podrá entrar Jamás
Nov 14 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 9:51 AM, Clay Smith <clay.smith.r gmail.com> wrote:
 Leandro Lucarella wrote:
 I'm sorry to bring up another "How about Go's ..." topic, but I think this
 feature is very in sync with D and it should be really easy to implement.

 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.

 Do you see any reasons not to do that? I think it happens very often to
 stop using some import and never notice it.

No, this is a job to be left to the IDE, not compiler.

Well, just a small argument for the contrary, but you may be importing some module precisely for the purpose of getting its module constructors to run. For instance the module constructor may have a call like RegisterComponent(thisModule) in it. Think of a set of image format loaders that register themselves with the main ImageLoader module. Then you call ImageLoader.load(filename). Nowhere in your code do you care if it is a PNG or not. You only need to use the ImageLoader's API. Also there's public imports. And all.d type modules with nothing but pubilic imports. There's no way an IDE can know about those intents. So that argues that there should be a way in the language to indicate "i know it doesn't look like I'm using this, but I am". And if that's in the language then the compiler might as well do the checking, too. Ok, not a super strong argument... unless D changed to compile things the way Go does, rolling in all deps. How about that one from Go? Including all deps in an obj. Could D use the same trick to speed up compilation further? --bb
Nov 13 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 14 de noviembre a las 14:59 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el 14 de noviembre a las 10:36 me escribiste:
Leandro Lucarella wrote:
Does this makes more sense?


It would be pushing to much to ask if you're willing to give it a serious thought then? =)

I understand it (I think), but I'm not as keen on it as you are <g>. Consider that D has function hijacking protection (I think this is unique to D) so that inadvertent overloading by the same names in different imports is virtually eliminated. So I think the marginal benefit of the proposed changes is small.

I can see that it would be too much trouble for too little gain (from you POV, I still think that readability is key for code-review, which I consider key for high-quality code). Can you at least consider making easier for people who consider this is an important feature? What I think it would do a big difference is some syntax sugar for this: import leaf = some.large.package.leaf; Making static imports have that semantic can be an option, but it could be bad for backward compatibility. Maybe final import? final import some.large.package.leaf; leaf.f(); This way I can easily put all my imports inside a final block: final { import foo.bar; import bar.baz; } -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- CHINO ATRAPA COTORRAS -- Crónica TV
Nov 14 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 10:23 AM, Clay Smith <clay.smith.r gmail.com> wrote=
:
 Clay Smith wrote:
 Bill Baxter wrote:
 On Fri, Nov 13, 2009 at 9:51 AM, Clay Smith <clay.smith.r gmail.com>
 wrote:
 Leandro Lucarella wrote:
 I'm sorry to bring up another "How about Go's ..." topic, but I think
 this
 feature is very in sync with D and it should be really easy to
 implement.

 Go issues an error if you have an import that's never used, to avoid
 unnecessary dependencies.

 Do you see any reasons not to do that? I think it happens very often =





 stop using some import and never notice it.


Well, just a small argument for the contrary, but you may be importing some module precisely for the purpose of getting its module constructors to run. =A0For instance the module constructor may have a call like RegisterComponent(thisModule) in it. =A0Think of a set of image format loaders that register themselves with the main ImageLoader module. =A0Then you call ImageLoader.load(filename). Nowhere in your code do you care if it is a PNG or not. =A0You only nee=



 to use the ImageLoader's API.

 Also there's public imports. =A0And all.d type modules with nothing but
 pubilic imports.

 There's no way an IDE can know about those intents. =A0So that argues
 that there should be a way in the language to indicate "i know it
 doesn't look like I'm using this, but I am". =A0 And if that's in the
 language then the compiler might as well do the checking, too.

 Ok, not a super strong argument... unless D changed to compile things
 the way Go does, rolling in all deps.

 How about that one from Go? =A0Including all deps in an obj. =A0Could D
 use the same trick to speed up compilation further?

 --bb

I'm not really understanding what you are saying,


It's not that complicated. Maybe try reading it again. And forget about the example of why you might want to import something without using it, just trust that there are legit cases where you might want to.
 but I see no need for
 the compiler to error on unused import. If anything, the compiler can ju=


 ignore it, or have a flag to find unused imports. I would like my all.d
 files to not give errors :o


Actually, I agree that the compiler should not error unused *public* imports. That really would not make any sense.
 Plus copy/paste imports from other modules, without compile error :o

Why do you want to paste in a bunch of unused imports? Wouldn't you like to know which ones you use and which you don't, and trim the fat? --bb
Nov 13 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 10:28 AM, Lutger <lutger.blijdestijn gmail.com> wrote:
 Justin Johansson wrote:

 No, sorry I am not informed on D's policy about warnings

Exactly. Ever wondered why that is? The policy is: there are no warnings.

Probably more clear to say "all warnings are treated as errors." --bb
Nov 13 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 11:15 AM, Clay Smith <clay.smith.r gmail.com> wrote:
 bearophile wrote:
 Clay Smith:

 I would like my all.d files to not give errors :o<

"all.d" files are a hack used to patch one of the minor holes of the current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *; Every part of a language needs to be designed with care. Approximate designs with several holes aren't enough. Bye, bearophile

That would be a nice feature.

It would be a convenient feature, but in both Java and Python where they have this feature, its use is frowned upon. --bb
Nov 13 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 11:12 AM, Clay Smith <clay.smith.r gmail.com> wrote=
:
 Bill Baxter wrote:
 On Fri, Nov 13, 2009 at 10:23 AM, Clay Smith <clay.smith.r gmail.com>
 wrote:
 Clay Smith wrote:
 Bill Baxter wrote:
 On Fri, Nov 13, 2009 at 9:51 AM, Clay Smith <clay.smith.r gmail.com>
 wrote:
 Leandro Lucarella wrote:
 I'm sorry to bring up another "How about Go's ..." topic, but I thi=







 this
 feature is very in sync with D and it should be really easy to
 implement.

 Go issues an error if you have an import that's never used, to avoi=







 unnecessary dependencies.

 Do you see any reasons not to do that? I think it happens very ofte=







 to
 stop using some import and never notice it.


Well, just a small argument for the contrary, but you may be importin=





 some module precisely for the purpose of getting its module
 constructors to run. =A0For instance the module constructor may have =





 call like RegisterComponent(thisModule) in it. =A0Think of a set of
 image format loaders that register themselves with the main
 ImageLoader module. =A0Then you call ImageLoader.load(filename).
 Nowhere in your code do you care if it is a PNG or not. =A0You only n=





 to use the ImageLoader's API.

 Also there's public imports. =A0And all.d type modules with nothing b=





 pubilic imports.

 There's no way an IDE can know about those intents. =A0So that argues
 that there should be a way in the language to indicate "i know it
 doesn't look like I'm using this, but I am". =A0 And if that's in the
 language then the compiler might as well do the checking, too.

 Ok, not a super strong argument... unless D changed to compile things
 the way Go does, rolling in all deps.

 How about that one from Go? =A0Including all deps in an obj. =A0Could=





 use the same trick to speed up compilation further?

 --bb

I'm not really understanding what you are saying,


It's not that complicated. =A0Maybe try reading it again. =A0And forget about the example of why you might want to import something without using it, just trust that there are legit cases where you might want to.

ok
 but I see no need for
 the compiler to error on unused import. If anything, the compiler can
 just
 ignore it, or have a flag to find unused imports. I would like my all.=




 files to not give errors :o


Actually, I agree that the compiler should not error unused *public* imports. =A0That really would not make any sense.

True
 Plus copy/paste imports from other modules, without compile error :o

Why do you want to paste in a bunch of unused imports? =A0 Wouldn't you like to know which ones you use and which you don't, and trim the fat? --bb

If I want to save time, and I'm developing a module similar to an existin=

 one, copying/pasting imports is 90% accurate and saves me time, which is
 invaluable.

But if the compiler told you which ones you weren't using it wouldn't take you much extra time to eliminate them. What really sucks up time is having to remove imports one-by-one and recompiling after each to try to figure out which imports you need and which ones you don't. --bb
Nov 13 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 11:36 AM, Clay Smith <clay.smith.r gmail.com> wrote:
 Bill Baxter wrote:
 On Fri, Nov 13, 2009 at 11:15 AM, Clay Smith <clay.smith.r gmail.com>
 wrote:
 bearophile wrote:
 Clay Smith:

 I would like my all.d files to not give errors :o<

"all.d" files are a hack used to patch one of the minor holes of the current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *; Every part of a language needs to be designed with care. Approximate designs with several holes aren't enough. Bye, bearophile

That would be a nice feature.

It would be a convenient feature, but in both Java and Python where they have this feature, its use is frowned upon. --bb

I don't understand why its frowned upon, if you really want to see what you are importing then look at the folder where the import is coming from.

Here's what I could dig up: http://www.omahapython.org/IdiomaticPython.html#importing The more unnecessary stuff you have in your namespace the harder it is for people to figure out what your code is doing. Also using "import foo.*" means that the addition of a file could cause your program to stop compiling since a previously unambiguous symbol becomes ambiguous. But I guess it remains even in Python 3 because it's quite handy for writing small scripts. --bb
Nov 13 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 2:31 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 bearophile wrote:
 Nick Sabalausky:
 I used to think so, but I'm not so sure anymore.

It's the same for me. I can live without the *, as I can live without D typedef. There are other changes/fixed that I want for the module system still.

Are they in bugzilla? bugzilla: That stone will be eventually turned and looked under. You will bask in the glorious sun of well-deserved recognition. newsgroup: None of that good stuff.

313! 314! But I don't know if that's what bearophile had in mind... --bb
Nov 13 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Clay Smith, el 13 de noviembre a las 13:20 me escribiste:
How about that one from Go?  Including all deps in an obj.  Could D
use the same trick to speed up compilation further?

I'm not really understanding what you are saying, but I see no need for the compiler to error on unused import. If anything, the compiler can just ignore it, or have a flag to find unused imports. I would like my all.d files to not give errors :o

It's good to avoid unnecessary dependencies, which can be very bad for compilation time of big projects (something that D, like Google's Go, intent to fix). You can see the Google's Go video presentation in YouTuve for the reasons why unnecessary dependencies are bad for fast compilation. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- I always get the feeling that when lesbians look at me, they're thinking, '*That's* why I'm not a heterosexual.' -- George Constanza
Nov 13 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 13 de noviembre a las 14:10 me escribiste:
 Clay Smith:
 
I would like my all.d files to not give errors :o<

"all.d" files are a hack used to patch one of the minor holes of the current D module system.

That's true, I like the Google's Go aproach: no modules, just packages. All files in a directory are part of the same packages, so you can split a package in several files without increasing the packages system nesting level too much (as it happens in D). But "fixing" the D module system is too big, so I'm asking only to flag unused imports for now ;) I *really* like the interfaces+embedding of Google's Go, it's similar to interfaces+mixins in D, but taken a little further, but that's a very big change too and I don't think D will ever take that road. Too bad.
 The right way to do that is with a syntax like (that must not import the
 'foo' name too in the current namespace, only the names inside
 "std.foo"):
 
 import std.foo: *;

I like very much this too about Google's Go: when importing a nested package, to use its symbols you just have to type the leaf: import "std/foo"; foo.Something(); // instead of std.foo.Something(); This helps a lot with large names and, in conjuntion with packages being distributable among multiple files, removes the need for an import foo.all; -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- For long you live and high you fly But only if you ride the tide And balanced on the biggest wave You race towards an early grave.
Nov 13 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Nick Sabalausky, el 13 de noviembre a las 17:06 me escribiste:
 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:hdkavm$1b0k$1 digitalmars.com...
 Clay Smith:

I would like my all.d files to not give errors :o<

"all.d" files are a hack used to patch one of the minor holes of the current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *; Every part of a language needs to be designed with care. Approximate designs with several holes aren't enough.

I used to think so, but I'm not so sure anymore. In my Goldie project, one of the modules ("goldie.file") is something with a whole lot of types and details about loading a .cgt file. In the vast majority of use-cases, the Goldie library user has no reason to use any of those directly, so as useful as "goldie.all" is, it would be pointless for me to include that "goldie.file" in "goldie.all", which is exactly what "goldie.*" would do automatically if it existed. Now, certainly, I could just mark everything in "goldie.file" as private, but I do want people to be able to import and use it directly if they want to (Ex, if they want to use Goldie as a springboard for their own .cgt-file handling routines). Plus, I'll often have renamed and deliberately unused source files in the same directory as "real" modules, and I wouldn't want them automatically grabbed by ".*". I suppose I could change their extension, but then the editor would get confused, and I'd have to work around that, etc...

In Python you have the special variable __all__ to mark what do you want to export when using *. Something similar can be used for this. But I think import * is a hack, and if somebody use it, he/she should accept the consecuences (polluting the file with all goldie.file symbols). I don't think it worth encouraging the use of import * by adding features to it. I think it should exist, the same I think goto should exist, but the programmer should be aware of its implications. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Long you live and high you fly And smiles you'll give and tears you'll cry And all you touch and all you see Is all your life will ever be.
Nov 13 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Nov 13, 2009 at 4:29 PM, Lutger <lutger.blijdestijn gmail.com> wrote:
 Bill Baxter wrote:

 On Fri, Nov 13, 2009 at 10:28 AM, Lutger <lutger.blijdestijn gmail.com>
 wrote:
 Justin Johansson wrote:

 No, sorry I am not informed on D's policy about warnings

Exactly. Ever wondered why that is? The policy is: there are no warnings.

Probably more clear to say "all warnings are treated as errors." --bb

Note there is no way to treat warnings as warnings, making those 'warnings' just errors that can be turned on or off. Since there are no warnings to begin with, there are no warnings to treat as errors. I think that better reflects the idea that according to Walter, the concept of a compiler warning is inherently broken and thus rejected. Your code either compiles or not, which goes against the idea of what warnings are.

We're just splitting hairs here, but the nuance I got from "there are no warnings" is that there are no checks ever performed of the type most compilers call warnings. That's not true. It does perform those kinds of checks with the -w flag, it just causes the compilation to fail when such things are found. So all I'm sayin' is that if you're trying to actually be helpful, then a better explanation is "all warnings are treated as errors". If just want to make a political point, maybe your way is better. --bb
Nov 13 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 13 de noviembre a las 14:31 me escribiste:
 bearophile wrote:
Nick Sabalausky:
I used to think so, but I'm not so sure anymore.

It's the same for me. I can live without the *, as I can live without D typedef. There are other changes/fixed that I want for the module system still.

Are they in bugzilla? bugzilla: That stone will be eventually turned and looked under. You will bask in the glorious sun of well-deserved recognition.

OK, I just went through a quick search on module system related bugs (not because I want any recognition, just because we all know that bearophile will never report a bug in bugzilla =P) and "marked" them with [module] and reported a couple of feature requests too. I didn't included cyclic/forward references bugs though: http://d.puremagic.com/issues/buglist.cgi?quicksearch=[module] Hope it helps... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Do not get mad with others Because they know more than you It is not their fault
Nov 13 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 13 de noviembre a las 18:17 me escribiste:
 bearophile wrote:
Clay Smith:

I would like my all.d files to not give errors :o<

"all.d" files are a hack used to patch one of the minor holes of the current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *;

Sorry, I think that * approach is far worse as you never can be sure what it is picking up.

!? import std.foo: *; is the current behavior for import std.foo;! -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Yo soy Peperino, mártir latino, venid al asado pero traed el vino. -- Peperino Pómoro
Nov 13 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sat, Nov 14, 2009 at 5:17 AM, bearophile <bearophileHUGS lycos.com> wrote:

I didn't included cyclic/forward references bugs though:<

You may add them too.

I think this word "may" does not mean quite what you think it does. What you wrote there basically means "You have my permission to add them, too", like a teacher might say to a student. I suppose on the books "may" and "might" have similar meanings. "It may rain tomorrow" is pretty much the same as "it might rain tomorrow". But "may" has this extra meaning of permission to do something that you have to watch out for. If it can be interpreted as giving permission, it will be. "Might" doesn't have that ambiguity. In the above situation, I would say either "It might be a good idea to add them too". Or just ask directly "Could you please add them, too?" --bb
Nov 14 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sat, Nov 14, 2009 at 5:17 AM, bearophile <bearophileHUGS lycos.com> wrote:
 Leandro Lucarella:

 and "marked" them with [module]

Thank you for your work. This is good: http://d.puremagic.com/issues/show_bug.cgi?id=3503 Once all those things are fixed, the module system will start to look OK regarding *modules*, but I think the semantics of the packages and their usage will need some tuning still.

I used to be for such a change, but I'm not sure anymore that it's a good idea for D. See the comment I added to the report. One thing that I'd like would be a DRY way to use the leaf name of a module. Often I end up writing things like: import MyModule = foo.bar.MyModule; Maybe something like this could be allowed to mean the same thing: import (foo.bar.)MyModule; I think this has been brought up before, but I don't recall any good suggestions. --bb
Nov 14 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
bearophile, el 14 de noviembre a las 08:17 me escribiste:
 Leandro Lucarella:
 
 and "marked" them with [module]

Thank you for your work. This is good: http://d.puremagic.com/issues/show_bug.cgi?id=3503 Once all those things are fixed, the module system will start to look OK regarding *modules*, but I think the semantics of the packages and their usage will need some tuning still.

I know it's useless to ask, but can you fill bugs with the enhancements your think the package system should have? It's not enough to post some links about how other languages do it. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Ever tried? Ever failed? - Try again! Fail better!
Nov 14 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Yigal Chripun, el 14 de noviembre a las 10:32 me escribiste:
 On 14/11/2009 00:28, bearophile wrote:
Nick Sabalausky:
I used to think so, but I'm not so sure anymore.

It's the same for me. I can live without the *, as I can live without D typedef. There are other changes/fixed that I want for the module system still. Bye, bearophile

once upon a time there was a suggestion to have a special file that would define the public API of a package. e.g. myPackage a.d b.d ... this.d // special file that defines the public imports private.d // should not be imported by a "*" import then, the user can import myPackage.* and that would search for this.d in the directory and use its contents instead of importing all d files in the directory.

This is nice too (same as Python's uglier __init__.py =). Can you add a bug report for this with the subject starting with [module]? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Are you such a dreamer? To put the world to rights? I'll stay home forever Where two & two always makes up five
Nov 14 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 13 de noviembre a las 20:56 me escribiste:
 Leandro Lucarella wrote:
Walter Bright, el 13 de noviembre a las 18:17 me escribiste:
bearophile wrote:
Clay Smith:

I would like my all.d files to not give errors :o<

current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *;

what it is picking up.

!? import std.foo: *; is the current behavior for import std.foo;!

I thought you were asking for all .d files in the directory foo?

Nope. Bug 3504 is about this: mod.d: void f() {} pkg/a.d: void f() {} pkg/pkg.d: void f() {} x.d: import mod: *; import pkg: *; void main() { f(); // mod.f a.f(); // pkg.a.f pkg.f(); // pkg.pkg.f } I added the example to the bug report for clarification. http://d.puremagic.com/issues/show_bug.cgi?id=3504 Here is an example if all 3503, 3504 and 3505 gets implemented: mod.d: void f() {} pkg/a.d: void f() {} pkg/pkg.d: void f() {} some/large/package/a_module.d: void f() {} x.d: 1 import mod: *; // doesn't introduce the symbol 'mod' 2 import pkg: *; // introduce the symbol 'pkg' but refering to pkg.pkg 3 import some.large.package.a_module; // introduce the symbol 'a_module' 4 static import some.large.package.a_module; 5 6 void main() { 7 f(); // mod.f (from line 1) 8 a.f(); // pkg.a.f (from line 2) 9 pkg.f(); // pkg.pkg.f (from line 2) 10 a_module.f(); // some.large.package.a_module (from line 3) 11 some.large.package.a_module.f(); // (from line 4) 12 } I added this example to bug 3503, which is the one that makes 3504 and 3505 more useful. http://d.puremagic.com/issues/show_bug.cgi?id=3503 Does this makes more sense? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- No recuerdo las flores, no conozco el viento Aquí donde envejecen juntos presos y carceleros Los días no pasan, el tiempo no pasa Y vivimos contando el tiempo Y moriremos contando el tiempo
Nov 14 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 14 de noviembre a las 10:36 me escribiste:
 Leandro Lucarella wrote:
Does this makes more sense?

Yes.

It would be pushing to much to ask if you're willing to give it a serious thought then? =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Que barbaridad, este país se va cada ves más pa' tras, más pa' tras... -- Sidharta Kiwi
Nov 14 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
KennyTM~, el 15 de noviembre a las 03:17 me escribiste:
once upon a time there was a suggestion to have a special file that
would define the public API of a package.

e.g.

myPackage
a.d
b.d
...
this.d // special file that defines the public imports
private.d // should not be imported by a "*" import

then, the user can import myPackage.* and that would search for this.d
in the directory and use its contents instead of importing all d files
in the directory.

How is it different from using an all.d and import myPackage.all ?

It will just make importing shorter (and it will encourage people to use the "all" trick as it's part of the language and not just a convention). -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Sé que tu me miras, pero yo me juraría que, en esos ojos negros que tenés, hay un indio sensible que piensa: "Qué bárbaro que este tipo blanco esté tratando de comunicarse conmigo que soy un ser inferior en la escala del homo sapiens". Por eso, querido indio, no puedo dejar de mirarte como si fueras un cobayo de mierda al que puedo pisar cuando quiera. -- Ricardo Vaporeso. Carta a los aborígenes, ed. Gredos, Barcelona, 1912, página 102.
Nov 14 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Sat, Nov 14, 2009 at 12:45 PM, bearophile <bearophileHUGS lycos.com> wrote:

 I hope this too is acceptable: "You might add those too" :-)

It's ok but it still sounds a little odd to me, as if know one knows if it will happen or not. Similar to "it might rain tomorrow". It might happen, it might not, but there's nothing anybody can do about it.
 Thank you very much for your English lessons,

No prob. --bb
Nov 14 2009