Hi, Sarosh

I agree wwith Trey and in most cases I use this kind of code hooks. Maybe it is just the way I used to work before, but it seems more safe and it keeps the interfases cleaner and more encapsulated.

I always try to avoid having to DoDefault() because you have to KNOW somehow what the parent class is actually doing to decide whether you have to call it before or after your instance code, and this is not my idea of independent components.

Either way, I don't think that VFP behaviour would change in this aspect, as VFP developers have already struggled with the inheritance issues and changing it would complicate matters for a lot of people (beside breaking old code).

Just opinions of mine...


>I tend to agree with the others who have said that the way it is works pretty well, and to change the methodology would break so much code it wouldn't be worth it (unless of course enough other things broke enough code as well, but I digress).
>
>However, I also rather prefer coding the superclasses so I don't have to use DoDefault() very much. e.g., a typical Save() method.
>The superclass Save() contains all the necessary code to save any data, w/o needing any coding at the child level.
>The only child specific code needed would be to check required fields and to validate data using other business rules.
>In this case, the superclass would have the CheckRequiredFields() and IsValid() methods (as an interface), with no default code except to maybe return a value indicating success (RETURN .T. or RETURN 0, etc.).
>The CheckRequiredFields() and IsValid() methods are overwritten by the child level. In none of these methods would a DoDefault() be required in the child.