But you still can't run without the other files compiled, am I right?
The point is that by keeping each class in its own file, you only need
to touch the files which have changed and any dependencies. You don't
need to rebuild the larger jar files - whereas you *do* have to build
the full assembly in .NET. (Yes, using modules would help this, but
it's a pain.)
I suggest moving to Vb.Ne then, as you will have that feature there,
although I must say this doesn't really come up much because of
Intellisense.
I gather it slows things down significantly with larger projects
though - or at least did at one point. Either way, there's a
psychological difference between "I'll trust that the as-you-type
compiler has spotted all the errors" and "The code is actually built
and can be run, and I have no errors".
Does it make sense to run a test when some of the modules may not have
been built?
Everything *will* have been built though. That's the point - it's
incremental.
(Actually, Eclipse will let you run code even if you've still got
compilation errors - you'll get a runtime error when you enter the
method or type that failed to compile. It warns you on launch, of
course.)
How? What is the point of testing each single line change? Running
tests too often is just a waste of time. Most of the changes I need
to make are not trivial that I can code it in a few seconds and then
be ready to test it. The coding takes far longer than the compilation
time.
I don't necessarily test every single line change, but I try to test
every functional change - and rerunning the unit tests very frequently
helps with that.
TDD is all about making small changes and making sure they work. If
you're not a TDD fan, fine - but please don't assume that just because
a relatively slow compile cycle doesn't hurt *your* productivity, it
doesn't hurt that of other people.
So what? Again, if its that important to you, go to Vb.Net. Vb.Net
supports background compilation.
Actual background compilation, or just background error checking?
There's a big difference between the two. (Besides, I far prefer the
C# language to VB.NET.)
Thats not true at all. The more files you have, and the more code in
them, the longer it will take to compile.
That's because it's not an incremental compiler, as I say. In Eclipse,
if I change one method, even in a *giant* class, IIRC only that method
will actually be recompiled (and the whole class file regenerated). If
I change the method signature, other things which depend on it will be
recompiled. It doesn't need to recompile whole projects - only
dependencies.
Dependant projects need to
be recompiled when their dependancy changes. Perhaps you are stuffing
too much into one assembly, or you simply have a slow machine.
My machine is reasonably nippy, but it still takes 10 seconds to
compile the solution I'm largely working with at the moment.
So it's a pain in the neck, particularly for TDD developers. Have you
used Eclipse for significant projects? It's sometimes hard to
appreciate what a difference such features can make without having
experienced them for yourself.
I often talk about features like "Open Type" in Eclipse, and people
who haven't used Eclipse say they can easily live without it. I
haven't yet met anyone who *has* used Eclipse for significant periods
who doesn't agree that it would be a *huge* benefit to have in VS2005.
(Fortunately, ReSharper provides it. Shame it's not in VS itself
though.)
Jon