Ary Borenszweig wrote:
Lars Ivar Igesund escribió:
Yigal Chripun wrote:
Denis Koroskin wrote:
On Sat, 20 Dec 2008 20:41:23 +0300, Yigal Chripun <[email protected]>
wrote:
Denis Koroskin wrote:
On Mon, 15 Dec 2008 10:58:23 +0300, Bill Baxter <[email protected]>
wrote:
For me, V1.038 compiles my code but takes a really really really
long
time to do so.
It now takes 1 min 20 secs for a full build, when it used to compile
in 13 seconds.
Forget the 60% slowdown from LDC -- this is 515% slower!
(building with DSSS and tango)
--bb
I generally make all my imports private and run a command line tool
that strips unnecessary imports once in a while to minimize
intermodular dependencies. Maybe it could help in your case, too?
When programming in Java, Eclipse knows to handle all of this for you.
it will suggest adding missing imports, it can remove unused imports
and it can convert a foo.bar.* into a list of the specific modules you
actually used in the code.
I wish that kind of tool would be available for D. Is this
functionality implemented in descent? if not, is it planned?
I do realize that it's more difficult to do this for D than it is for
Java, because of Conditional compilation and other issues already
mentioned in this thread. But it would be awesome if I could just
write:
Stdout("whatever").newline;
and get a quick-fix action (Ctrl+1) to add tango.io.Stdout to the list
of imports.
--Yigal
You should watch Descent videos on youtube, it is *much* smarter that
that!
http://www.youtube.com/user/asterite
I watched the video.
the functionality is that if you write: new Foo; it added automatically
an import for Foo. that's very cool and all but I was asking for
something more than that.
for Java, Eclipse can add and manage imports for you not only when you
do new Somthing() but also for functions - like recognizing that
Stdout("string") needs to import tango.io.Stdout. More over, if you
wrote some of the imports yourself, or edited some code and removed the
only call to some function, you can ask eclipse to orginize your imports
and it'll remove unneeded imports and expand Java's Foo.* kind of import
to a list of the actual modules the code needs.
Descent is a great project and I want to thank all the developers
involved in this great undertaking. All I'm saying is that it would be
nice to also have an "organize imports" function in Descent.
And you know for certain that it doesn't have this?
Yigal is right, Descent doesn't have that kind of functionality.
As I mentioned before, you'd need to try every possible
conditional-compilation setup combination to see which are the unused
imports.
Also, when I first implemented it, I thought about adding selective
imports in autocompletion, so that:
---
void foo() {
writefln| <-- autocomplete!
}
---
results in:
---
import std.stdio : writefln;
void foo() {
writefln(...)
}
---
and successive uses of symbols in std.stdio would add to the selective
import, but many people told me that selective imports have some
problems (I can't remember which were them right now).
Sounds awesome. if those problems (DMD bugs?) can be overcome, this
would be one of my favorite features in descent.
what about a compromise? for the sake of unused import elimination
assume that all possible versions are used. it's not that far off..
suppose I have:
import Foo;
import Bar;
version (foo) {
// use symbols from Foo here
}
version (bar) {
// use symbols from Bar here
}
removing either of the imports will be bad.
more advanced functionality would be to move the imports to inside of
the version blocks.
I haven' t thought this through yet, but even some of this would be
extremely useful. even if you just implement adding missing imports (and
requiring me to remove redundant imports myself manually).
Keep on the good work, and thanks for an awsome and very useful project!
-- Yigal
