Let me fill in where I can...

>Hi all,
>
>I just finished reading the "Understanding Interface-based Programming" article by Ted Pattison and have a few thoughts/questions for anyone who would care to respond. I think I'm getting the grasp of this - but am sure it is still incomplete.
>
>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.

An interface is the public PEMS and PARAMETERS.

>
>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.

I think what you're saying here is to just define a class, put in the parameters and custom methods, but no code.

This doesn't work the same way under the hood as Interface Inheritance.

>
>3 - Other than the fact that MS has chosen to force us down the path - I still fail to see why "Interface Inheritance" is any more advantageos than what I pointed out in #2? I'm sure I'm missing something, so anyone who can help - please do so!

Let's say you have a VFP class that is subclassed 100 times. Now, what happens when you make a change to the parent? You have to be concerned about how that one change affects 100 subclasses.

>
>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?

I'll leave this one up to people that know more VB than I do.

>
>thanks,