Abstract functions in child classes
schveiguy at yahoo.com
Mon Dec 5 05:41:50 PST 2011
On Fri, 02 Dec 2011 17:28:33 -0500, Jonathan M Davis <jmdavisProg at gmx.com>
> On Friday, December 02, 2011 21:13:45 Adam wrote:
>> Anyway, I have my answer, and I know that D *does* have a reason for
>> this implicitism.
> Okay. Maybe I've been skimming over this thread too much, but I don't
> understand what forcing the programmer to mark an abstract class as
> would do. The compiler knows that the class is abstract regardless. It's
> to generate an error when you try and instantiate that class - whether
> or not
> you mark the class as abstract or not has no impact on that as long as
> are abstract functions (the sole bizareness being able to mark a class as
> abstract when none of its functions are abstract).
If I may describe what I see as the argument for (while trying to avoid a
strawman), the benefit of requiring abstract is so the compilation of the
class fails, not the isntantiation of the class.
It's feasible that someone could run tests that don't ever instantiate
that exact class type, and then they wouldn't know it wasn't
instantiable. This is similar to someone who writes a library of
templated objects, but doesn't test certain instantiations of them,
finding out only later that it doesn't work. I actually have been
affected by this, since dcollections is all templates. For example,
containers of interfaces didn't work, but I didn't know until one of
dcollections' users tried to do it. Then I installed a workaround.
So to summarize, it's compiler error on declaration vs. compiler error on
instantiation. The question then becomes, given an expected concrete
class, what is the probability that nobody tries to instantiate it during
testing? The worst case scenario is that the end-user's code doesn't
> The only thing that I see that marking the class abstract does is give
> programmer a visual indicator that the class is abstract. I do think that
> that's valuable, and I'd love it if it were required when any functions
> in the
> class are abstract and disallowed when none are, but I don't see how it
> have any effect on what errors you're getting. It's instatiating an
> class which as error, not declaring one, and unless you actually
> it, there's no way for the compiler to catch it, because there's nothing
This can be fixed via ddoc (which should know the class is abstract).
In fact, I think it does mark it as abstract in documentation (I know it
marks interfaces as abstract unnecessarily).
More information about the Digitalmars-d-learn