Abstract functions in child classes

[Jacob Carlborg]

On 2011-12-01 19:18, Steven Schveighoffer wrote:
> On Thu, 01 Dec 2011 12:58:24 -0500, Regan Heath <regan at netmail.co.nz>
> wrote:
>
>> On Thu, 01 Dec 2011 17:50:48 -0000, Adam <Adam at anizi.com> 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