Re: Abstract Functions

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

Interesting. I could have sworn that I waved it in front of the compiler and
heard it whine about having an abstract function on a non-abstract tagged
type. You are saying that I have to derive a whole new class from the
non-abstract and tag that type as being abstract? Just goes to show one more
example of Originality Through Incompetence! :-) Maybe I'll take another
SWAG at it, but basically I found a "better" way of doing the job that
involved restructuring the class heierarchy some. Hence, now everything is
abstract until it becomes concrete. But its good to know that a solution
does exist.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Tucker Taft" <stt@avercom.net> wrote in message
news:3B53601D.1295AF39@avercom.net...
>
> That's not true.  Abstractness is *not* inherited.  An
> abstract type can have a non-abstract parent, and vice-versa.
> So you could have a useful non-abstract "grandparent" type,
> an abstract immediate parent, and then a non-abstract
> child of this parent.  Also remember that functions that
> return the type will automatically become abstract on
> inheritance, and thereby require overriding.
>