>>For me "abstract class" is merely a definition/description of usage: don't base an object on this class. In different languages there is more or less need for such consturcts: I see abstract classes really close to the definition of interfaces<g>.
>
>Close, yes.
>
>To be picky, the wikipedia article about template methods has a java example of an abstract game class (http://en.wikipedia.org/wiki/Template_method), which has abstract empty methods and one template method. Interfaces are mainly about seperation of definition and implementation. So an interface is more likely a special case of an abstract class then the other way around.

Did not mean it otherwise, but see how it could be read that way. What I meant was that having mechanisms like checking that a class is not instantiated or each method is implemented stem from the same mind set. And *can* be used for less/non redundant code (Java Tutorial):

When an Abstract Class Implements an Interface
In the section on Interfaces , it was noted that a class that implements an interface must implement all of the interface's methods. It is possible, however, to define a class that does not implement all of the interface methods, provided that the class is declared to be abstract. For example,

abstract class X implements Y {
// implements all but one method of Y
}

class XX extends X {
// implements the remaining method in Y
}

In this case, class X must be abstract because it does not fully implement Y, but class XX does, in fact, implement Y.

>Dont base an object on this class is really what

IF isabstract(This,This.class)
   debugout "instanciation of abstract class "+This.class
   error "instanciation of abstract class "+This.class+" is not allowed"
   Return .F.
endif

>is about. Whatever that isabstract() function would check.

Yupp, when "instance subclassing" you'd need to overwrite that method, as the aforementioned check on left(this.class, 1)="_" would still fail, as the parentclass is still the abstract one. From that POV you can argue that it is not "really" a abstract class since overwriting the mangled methods makes it concrete.

But as you loose many of "real" class benefits with such a strategy (you have to "implement" in each form again, reduncany threatens, no further augmentation of the former abstract class possible) that the question is why use an aggregation class pattern instead of pure method inheritance when purely going that route.
Calling form methods from the abstract method is a good answer to that. But the same *effect* could be had with dynamically adding a abstract class, setting a property in code which makes it "concrete enough" to work.

As we don't have "abstract" as a key word like in java (Wikipedia: Most object oriented programming languages allow the programmer to specify which classes are considered abstract and will not allow these to be instantiated. For example, in Java, the keyword abstract is used.) it is different in vfp and a IMHO a fringe case.

regards

thomas