>1 - the term "interface inheritance" seems to me to be a misnomer. I would think "interface referencing" or "interface implemntation" would be better - and this is where my initial confusion was coming from. To me - "inheritance" implies a parent-child relationship that doesn't seem to exists cleanly in what the article was talking about.
>

It's not a misnomer, it's a different use of the word than you are used to. In languages that support interface inheritance it is possible to state "this class will inherit from IHuntingdog". Stating this announces via your typelib that your class will support the Point and Retreive methods, as well as all of the methods required by by the interfaces that IHuntingDog inherits from: IDog (Bark, SniffCrotch) and IFourleggedAnimal (Walk, Breathe, PoopOnCarpet). When you declare in VB that your class will support IHuntingDog, VB creates these shell methods for you, and you are responsible for filling them out.

Sure, in VFP we can create all of these methods manually, but when our class is compiled they are defined as methods of the interface IMyClass. (or watever your class is called). So another program that is using your COM object has no way of knowing that your class can act like a hunting dog.


>2 - I fully understand that the COM-compliant mechanics of "Interface programming" is a specific feature that VFP currently does not have. However, it seems to me that the logical use of the paradigm is easily accomplished in VFP - namely - separating interface from impeementation - in VFP, typically through the use of containership or implementation object refrences.
>

VFP's inheritance is great, but it does nothing for COM interaction. See above.


>4- tech question - the article uses a VB example along the lines of:

Dim Dog1 as IDog <br>Set Dog1 = New CBeagle

What is the eqivalant VFP code to instantiate an object in this way - or does VFP not play on that side of the equatin either at this time?

These lines perform "early binding". The first line initalizes a variable as an object that supports IDog. This allows the VB design time to investigate the available PEMS of IDog and show them to the developer in the form of IntelliSense. The second line actually creates the object. Early binding is also faster at runtime than late binding because intimate details (function addresses) of the server are compiled into the client code. This allows the client code to bypass the step of looking up function addresses at run time.

Late binding doesn't compile any such details into the client. When a client uses late binding, the entire interface of the server is investigated at runtime.

VFP only supports late binding. This is disadvantageous in a couple of ways. Most obviously, we can't have intellisense without early binding. But perhaps just as importantly, we can't even instanciate objects that don't have "dual interfaces". That is, they don't support COM's IDispatch interface. IDispatch has methods that allow the client to look up methods to find the internal addresses of the functions in the dll (sort of like the early bound client did at compile time).

If you're wondering why anyone would ever want to use late binding at all, consider that early binding makes for a more fragile client: if the server is recompiled with new interface features, the client program that was compiled with early binding breaks because its detailed information about the server is now incorrect.

They both have their places, but currently in VFP, we don't have a choice: we have to use late binding.

An interesting excercise for someone that is learning this stuff is to open up the OLEView tool that comes with VS. OLEView uses all of the COM interfaces registered in the regitry (HKCR/TypeLib) to find and investigate all of the interfaces defined on your system. You can also look up a specific COM object by its ProgID, and see all of the interfaces it supports. Go ahead and compile a COM server for yourself and explore it with OLEView. You'll find that it supports an interface that VFP created for you (most likely named IYourClass: it will contain all of the properties and methods of your class), and IDispatch, which inherits from IUnknown, the only interface absolutely required by every COM object.