>>>>>>What exactly is the purpose of abstract classes in VFP?
>>>>>
>>>>>Declaring a class as abstract in OTHER languages makes sure that the class won't be instantiated directly. The idea is that the class is somehow incomplete, and that some details have to be filled in at a lower level.
>>>>
>>>>That's one idea that came to mind: Build in code that generates an 'error' when such an 'abstract' class is used in a concrete case. But it would probably be a ridiculous construction.
>>>>
>>>>>This can't be enforced in Visual FoxPro, but I suppose it still makes sense to use inheritance in such a way that the superclass isn't useful by itself. But again, there is no way to enforce it.
>>>>
>>>>Is there a good reason of are we just brainwashed to think that there is sense to use it?!
>>>
>>>Well, I think all this is very related to the concept of inheritance itself. It makes sense to define PEMs at different levels of an inheritance chain, and doing this, you might have "incomplete" classes at the upper levels of the hierarchy, and declaring them as "abstract" (say, in Java) would enforce that - avoid the programmer accidentally inheriting the wrong class.
>>>
>>>According to the Wikipedia, many dynamically-typed languages do NOT have abstract classes.
>>
>>Wikipedia.. (http://en.wikipedia.org/wiki/Abstract_type) Here's one more text from there.
>>In many dynamically typed languages such as Smalltalk, any class which sends a particular method to THIS, but doesn't implement that method, can be considered abstract. (However, in many such languages, the error is not detected until the class is used, and the message send results in an error such as doesNotUnderstand).
>>
>>As I interpret it, a class can/should also be mentioned abstract if it - let's say - contains a Save() method that is still totally empty. It is up to the developer to put code in the method in a child class.
>>
>>If that assumption is correct, then I also assume that it is a valid usage of an abstract class if it is DIRECTLY used in a form and if the Save() method is filled at that level!
>>
>>This implies an other definition of 'abstract class' than I had in mind sofar.
>>
>>>This, I think, has a certain similarity to being able to strictly declare a variable type. Being able to enforce this can avoid the programmer assigning the wrong type to a variable, through carelesness. Not having this feature you can also program, but you must be more careful, or simply put up with runtime errors that wouldn't appear in the other case.
>
>Oh, I see. Well, In Visual FoxPro, you can add properties and method code at the form level, making the form "similar to" a class. I don't remember enough Java, but I guess this is a little different from Java or other languages where classes are explicitly declared as "abstract".

Interesting idea. Are you saying here that for instance Java does not have the power to create additional properties and methods and fill or redefine methods in the instance? If that's the case, then our forms and DEFINE CLASS command might as well be regarded as a new child class creator just prior to the real instantiation. If this is a good working model, then using a so-called abstract class directly is a legitimate action in several or all cases.