David,
>I swear that it g3b wasn't triggering it, but it is now so I must have done something else.
gremlins happen sometimes here as well.

>
>>>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.
>
>I don't think so because all you have to do is check the inheritance along the line GraphicAbstractObject -> g1b -> g2b -> g3b. In a static classlib analysis it doesn't matter that gpolymorph is asking ox3 to draw().

I probably can imagine more fringe cases. Consider

define class G4b as G3b
  function draw()
     *-- here the abstract method is overwritten
     *-- it calls common fucntionality from N methods
     *-- takes an alternate approach to calling dodefautl()
     RETURN this.many_delegate(PROGRAM())

  function takelong()
     *-- here the abstract method is overwritten
     *-- it calls common fucntionality from N methods
     *-- takes an alternate approach to calling dodefautl()
     RETURN this.many_delegate(PROGRAM())

  function workslow()
     *-- here the abstract method is overwritten
     *-- it calls common fucntionality from N methods
     *-- takes an alternate approach to calling dodefautl()
     RETURN this.many_delegate(PROGRAM())

    FUNCTION Many_delegate(tcCallingMethod)
    	*-- more code common for many methods...
    	*-- call specific ancestor method in lieu of
    	*-- many dodefaults

    	*-- or part of a testing/logging framework
    	= this.log("Start " + tcCallingMethod)
    	LOCAL luRet
    	luRet = EVALUATE("g3b::" + JUSTEXT(m.tcCallingMethod) + "()")
    	= this.log("Stop " + tcCallingMethod)
    	RETURN  m.luRet
enddefine

But they really are fringe cases, and Abstractwarn doesn't have to be watertight in my view, as it is a help for developers.
>
>>Yes, but also in the case of
>

>>ox = CreateMyObjectViaTableBasedFactory("myClassHint", "myUnclearpathtotheVCX")
>>ox.draw()

>
>Object factories don't really enter into the equation. Your project would still contain the true vcx right? Whether or not the class myClassHint was really used in code wouldn't matter either in a static analysis of the classes in myUnclearpathtotheVCX and their entire inheritance tree. If you were not bundling your classlibs into the exe, you could create pseudo-projects that were used only for analysis of the inheritance tree.

At compile time you might not know which class will be instantiated. As long as "myClassHint" is a class where draw() is or already was implemented, everything is ok. But how does your static analysis figure out which classes are used with a call to their draw() method and have not implemented them ? Flagging all classes where draw() still isn't implemented creates unneccessary checking, if those "between" classes are never instantiated / have their draw()-method called.

>>It is difficult to be certain on which class inheritance level the draw method has to be implemented at least once.
>
>I thought a little bit about that yesterday, if you pulled the method code in and eliminated all the comments and the LPARAMETERS line and white space then if there was anything left you'd have implementation right? It may be a non functional implementation but who are we to decide what a developer does in their subclass? If the subclass doesn't work because of inadequate work on their part we can give them a warning.

Yupp, that's my take as well.

>
>Java on the otherhand plays fullblown policeman it won't even compile the subclass if the abstract methods are not implemented. That brings up the question if I wanted to leave G1.Draw() empty and delay the implementation until G2 can I do that in Java? I don't know and don't have a Java compiler handy to test it right now.

Not tested/verifyed, but from memory: the question goes a bit astray in java if seen from a "vfp-perspective". You are correct in the policeman description, but the implementation might be empty or just a return. The implementation as such defines the class to possess the methods described in the interface description (similar to the way vfp "implements" COM interfaces by creating empty placeholder methods to be used in eventhandler() function - just making sure the methods exist is enough, as then no error is triggered if the method is called. This is the "contract" aspect of interfaces: the compiler guarantees that the methods are "on" the class and you can call them anytime you want, even from G1. That is the reason the method sceleton HAS to exist on G1, even if no real functionality is given at that level.

In vfp just by defining the "abstract method" it is already guaranteed to exist on the class and all siblings, so the contract (read: no need to check with PemStat) is already fulfilled. From a java perspective I'ld describe this as already implemented with an empty method, which later can/should be overwritten. "Implementing" in vfp's context for vfp-abstract methods often describes overwriting the empty method, in contrast to the java usage, where that MAY happen later, but doesn't have to.

>>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...
>
>Currently I do just use a comment in the abstract method.

The latest vfp versions definitely helps by giving us the option to view inherited code right out of the property window. I try to minimize simple omission errors and one of the "visible" things is making sure the method commentary (the text after method name in reserved3 which is shown in the lower part of the properties window if you checked property definition in the right click menu) gives as many hints as I can foresee. Something I started back in vfp6 and kept on doing, even if the effect is diminished today compared to the vfp6 days.

regards

thomas