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 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
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.
 


 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?
 


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 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
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 reply 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
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
parent reply 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
next sibling parent reply 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.


 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?
 


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
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 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.


 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 =)


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.


 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 =)


 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 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 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
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 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.


 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


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.


 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


 
 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 reply 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 =










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. =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=






d

 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=




st

 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
parent reply 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.


 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


 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.


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
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=














nk

 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=














d

 unnecessary dependencies.

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














n

 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 importin=










g

 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 n=










eed

 to use the ImageLoader's API.

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










ut

 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. =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.=








d

 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=


g

 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 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
parent reply 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
next sibling parent reply 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<


 "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.
Nov 13 2009
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 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<


 "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


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 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 parent reply 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
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
next sibling parent reply 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
parent reply 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
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
prev sibling next sibling parent reply 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
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 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 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
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 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 reply 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
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 reply 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
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 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 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 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
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<


 "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;!


I thought you were asking for all .d files in the directory foo?
Nov 13 2009
parent reply 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<


"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;!


 
 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
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 Does this makes more sense?


Yes.
Nov 14 2009
parent reply 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
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?


 Yes.


 
 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 reply 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?


Yes.


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
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?


 Yes.


 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).


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