Thomas,

>True, but you can fake it (sort of...<g>)

That would do it, but at the cost of explicitly requiring no dodefault() call in the the subclass. This is dangerous because it's only true at the first level of subclass . And since you may not know when code at a higher level will be inserted. For example:

activate window "debug output"

ox = createobject( "g2" )
ox.Draw()

oy = createobject( "g2a" )
oy.Draw()
return

function AbstractWarn()
  local lcSetAssert
  lcSetAssert = set("Assert")
  set Assert on
  assert .f. Message Program() + " should be overwritten !"
  set Assert &lcSetAssert

define class GraphicAbstractObject as custom
   x = 0
   y = 0

function moveTo( newX, newY )
  = AbstractWarn()
endfunc

function draw()
  = AbstractWarn()
endfunc

enddefine

define class G1 as GraphicAbstractObject
function draw()
debugout 'level G1'
return
enddefine

define class G2 as G1
function draw()
dodefault()
debugout 'level G2'
return
enddefine

define class G1a as GraphicAbstractObject
enddefine

define class G2a as G1a
function draw()
dodefault()
debugout 'level G2'
return
enddefine

ox outputs as expected, oy will throw the assert because of the dodefault() call with no method override at the G1a level. So you'd be forced to remove the dodefault() from G2a, but when the G1a class designer decides that they have to provide implementation of the Draw() method they've broken the G2a class because it won't execute the inherited G1a code.

Add a third level of subclass to the mix and the complications grow. I prefer that classes always be written so that it's appropriate to always include a dodefault() at some point in the subclass method code. The few times where an explicit override without a call to the inherited code is required I document it in the code.

My personal choice for abstract methods/classes are comments in the abstract method code as well as the class design documentation.