On 2011-12-01 19:18, Steven Schveighoffer wrote:
On Thu, 01 Dec 2011 12:58:24 -0500, Regan Heath <[email protected]>
wrote:
On Thu, 01 Dec 2011 17:50:48 -0000, Adam <[email protected]> wrote:
Ok, starting to feel like I'm missing something obvious...
This:
void main() {
Child child = new Child;
}
also produces the (expected) error. Basically dmd was letting you get
away with the abstract class because you never instantiated it.
Child child;
is just a reference to a Child class.
You could argue the compiler should error in either case, in fact, I
would. But perhaps there is a good generic programming reason not
to... someone more experienced might be able to shed some light on it.
A Child reference could be for a further derived GrandChild type that
does actually implement the required functions. In fact, Child is also
abstract, it just isn't required to be marked as such.
All marking a class as abstract does is make it uninstantiable, just
like having an abstract method does. However, you can mark a class
abstract to prevent it from being instantiated, even when none of its
methods are abstract (could be useful in some situations).
However, I have no idea why you'd mark a concrete function as abstract.
That seems like a "just because we could" feature.
-Steve
The method in the super class could provide a partial implementation
that sub class can call. But that might be better divided in two methods.
--
/Jacob Carlborg
