Thomas,

For me abstract methods fall into two practical categories. 1) It is a fundamental method of the operation of the class that is being called from a controller method of the class. So if this method isn't filled in by the subclass the object basically doesn't do any useful work and it is pretty easy to spot that oversight. 2) It's a hook method where a subclass may or may not need to put code, if it is never overridden at any level of inheritance it's not an error.


>? If I put the code in a program, it works (since the "prg" is the extension at level -2) - as levels with empty methods are not put on the stack. If you working from the command window, there is the chance that "calling levels" are not there, which I meant in my update.

I tested that 3 level right from inside that prg fragment I'd posted, I didn't try it but in that case I think the -2 needs to be replaced by a -3 to trigger the assert.

>But the code should fail miserably when running against polymorphic usages:

>ox = createobject( "g3b" )
>op = createobject( "gpolymorph" )
>op.draw()
>
>define class gpolymorph as Custom
>  function draw()
>     *-- calling from here (existance of the callee assumed)
>     *-- breaks the assert check, since the polymorphic method does not
>     *-- implement a method of the abstract class.
>     ox.draw()
>enddefine
>
>define class G3b as G2b
>enddefine

That's still an abstraction failure right? The draw() method isn't implemented anywhere along the g3b inheritance tree.

>Implementing the check at compile time sounds like a nice approach, since also checking against the above problem might give you a hefty runtime penalty if done often/always. But I suppose such a builder might encounter some difficulties as well: first bump i visualze would be differing factory patterns from class loading via table down to makro expansion... Unless you do a static check on all classes included and even flag methods which are not overwritten but also not called in the current system.

It'd be a truly odd design that implemented dynamic inheritance ala:

define class x as &y

In classlibs everything has static inheritance so I think it can be done by a parse of the classlibs in the project. I'd see that you'd put a special marker in each abstract method:

* Abstract method must be overridden

actually I just thought for my #2 item above the marker could be:

* Abstract method might be overridden

or make it parameterized:

* Abstract method - override: [required | optional]

>Such an assert for me is more of a wakeup-call to make sure I don't forget implementing a certain feature...