Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Correlations among VFP and OOP languages
Message
From
14/06/2006 03:11:22
 
General information
Forum:
Visual FoxPro
Category:
Object Oriented Programming
Miscellaneous
Thread ID:
01128092
Message ID:
01128905
Views:
22
Hi David,
>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.

I've added all cases together, and when run as a prg, it works as I expected / described. The 3rd level of inheritance with all empty methods triggers the assert, as no implementation method exists to supply the correct method name equal to the abstract method. Program(n) counts the levels of methods with code on the stack. Just copy to "David.Prg" and let it run... Perhaps your test was on objects already loaded with "execute selection" - that would fall under the needed error checking I mentioned <bg>.

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

Yeah, and fixing that would be propbably be UGLY.

>It'd be a truly odd design that implemented dynamic inheritance ala:
define class x as &y
Yes, but also in the case of
ox = CreateMyObjectViaTableBasedFactory("myClassHint", "myUnclearpathtotheVCX")
ox.draw()
It is difficult to be certain on which class inheritance level the draw method has to be implemented at least once.

>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
Why not use the commentary fields for that ? They can be accessed programatically as well AND the developer sees the hint even when working on siblings of the base class. Just make your own rule, that the first line is for automatic parsing as well...

regards

thomas
 activate window "debug output"

ox = createobject( "g2" )
ox.Draw() && no dodefault, so no chance of assert

oy = createobject( "g2a" )
oy.Draw() && assert suppressed because called by implemented method,
		  && but has dodefault and the better way of coding can be used

o3x = createobject( "g3b" )
*-- should trigger, as no implementation method exists
o3x.Draw()  && assert not triggered ? triggers in germany when run as a prg...

op = createobject( "gpolymorph" )
* Here is also no Implementation method, but the assert is not
* triggered because the call stems from a polymorph method.
* At the moment I can think only of ugly / slow ways to force an assert
* here as well
op.draw() 

*-- just make sure the asserts are still working...
o3x.draw()

return

function AbstractWarn()
  local lcSetAssert, lcAbsCaller
  lcAbsCaller = Program(program(-1)-1)
  if not JustExt(m.lcAbsCaller)==JustExt(Program(program(-1)-2))
    lcSetAssert = set("Assert")
    set Assert on
    assert .f. Message m.lcAbsCaller + " should be overwritten !"
    set Assert &lcSetAssert
  endif

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

define class G1b as GraphicAbstractObject
enddefine

define class G2b as G1b
enddefine

define class G3b as G2b
enddefine

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.
     o3x.draw()
enddefine
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform