On Fri, 27 Apr 2012 03:36:48 -0400, Nick Sabalausky
<[email protected]> wrote:
Consider this:
abstract class Base
{
void foo(); // Oops! Forgot "abstract"!
}
AIUI, that's *legal* because of two things:
1. Abstract classes are allowed to include functions that *do* have
implementations.
2. D's compilation model, inherited from C, allows functions to be
implemented in a separate source file if you use function stubs, such as
above.
In D's abstract classes, wanting to include an abstract function is much,
much more common than wanting to include
separate-compilation/function-stubbing. So get it wrong, and thanks to
those
two normally-benign features above, you're treated to a mangled, ugly
linker
error and the associated deep-sinking feeling of "......Fuck!"
Now, maybe I was simply being stupid, but I just wasted two full days
getting tripped up by this damn, uhh, non-bug. Completely reworked my
whole
approach at least a couple times trying to work around...the wrong
issues.
Even ran DustMite a couple times trying to get a test case demonstrating
(what I *thought* was) DMD forgetting to instantiate some templated code.
Only to eventually solve the whole damn thing by just simply typing in a
stupid...little..."abstract ". Ugh.
The fact that optlink crashed while spitting out the errors certainly
didn't
help point me in the right direction. That's, of coruse, in addition to
the
"Symbol undefined" errors including some fun red herrings that appered
to be
from inside druntime/phobos.
There is an issue in bugzilla for this, #6485 (
http://d.puremagic.com/issues/show_bug.cgi?id=6485 ), but
*unfortunately* I
think it's invalid for the reasons I described above. However, maybe it's
just frustration over the last couple days talking, but I think at least
*something* should be done about this, even if it's not what #6485 is
requesting.
Thoughts?
You have my sympathy. Since working with D, I don't think I've *ever*
used the "declare then implement" model. My personal opinion is that the
compiler should require .di files for declaring stubbed methods.
Other than that, I don't see a way to "fix" this problem, because you
absolutely have to be able to declare an abstract class with non-abstract
methods. If you want a fully abstract class, use an interface ;)
Another thought, burn this into your neurons:
abstract class C
{
abstract:
...
}
At least you only have to type it *once*. Of course, you'd have to put
all concrete methods before the abstract, which may hinder organization of
your methods.
No really good solutions, sorry :(
-Steve
