>>>But can these class definitions be subclassed?
>>
>>In the same manner as VFP? No. But, you can implement the interface and operations of a class. So, you can achieve the same thing. To which I say, if I can achieve the same results with bascially the same effort, what's the difference.
>
>Well, this is not subclassing. The object you use for referencing the original is another object. If you enhance the original class (adding properties, events or method) you've got to enhance your wrapper also. I agree this is the best solution within VB but it's more tricky.
>
>
>Walter,


No, it is not subclassing. However, your description of what is happening is not accurate either. In this case, I am talking about classes, not objects. First off, I do wan't to say that VFP's way of handling subclassing an OO is superior to that of VB's. However, the situation for VB is not entirely gloom either.

Here is an example.

Let's say you have a simple VB class called classone, which has one method called mymethod that returns a string representation of the system date. Here is the code:

Public Function MyMethod() As String
MyMethod = Date
End Function

Now, let's say you want to modify this behavior slightly by prefixing the return string with "Today's date. We will do this in ClassTwo. Here is the code:

'General Declaration
Dim oClassOne As New ClassOne

Public Function MyMethod() As String
Dim strDate As String
strDate = oClassOne
MyMethod = "Today's Date is " & strDate
End Function

In this case, we create an instance of the first class, and have implemented the same interface. In this case, there is only one method called MyMethod. If you change the behaviors of the ClassOne, those changes will be reflected in calls to MyMethod of ClassTwo.

Now, is this subclassing? I would say no, it is not.
Would I say, have we achieved the same end result? Yes, I would say so.
Would I say that VFP's method of accomplishing these task better? Yes, I would.
However, would I also say that VB's way of doing things is a workable? Yes, I would.

Now, it is important to note that I slightly mis-spoke when I used the word implements. I have to be careful here because VB has a keyword called Implements. In VB, you can implement the interface of a class without the functionality, and without the creation of a class hierarchy. This is a neat feature when you think about it. Often, all I have ever wanted was an interface definition. I may not want to inherit the behaviors. I do however, want to keep the interface constant. In VFP, we really do not have a way of doing this. Our sole way of doing anything remotely to this is inheritance. And, in many cases, that works fine. However, there are cases when inheritance is not what you are after. Rather, all you care about is the interface.

And one final word on this. In the world of COM, this, not the VFP way of doing things, is how things work....

It's different, but it is not *that* tricky...