i have a legacy COM components, as part of upgradation i derived from an existing interface
interface1 { few methods }
interface2 :public interface1 { new methods }
there was an old review comment not to do this..instead have inteface2 has separate one not deriving from the base, as it part of the same CoClass...there is no need to duplicate any code...
review comment : Scripting languages are interpreted languages and are naturally polymorphic as all methods are late bound. All variables are typeless (VARIANT is typeless). However, there is a separate problem concerning scripting languages. Scripting languages do not use the virtual function table in order to invoke methods on a COM object but instead invoke methods via the IDispatch interface. Unfortunately IDispatch can only be associated with one custom interface. All methods accessed via IDispatch must be part of the custom interface
can anyone explain ...does he mean to say that getidsofnames will not be able to return the correct ID ? or is it something else
It is accurate enough, a coclass can implement multiple interfaces. But one is "special", it is the one that's attributed with [default] in the IDL. Scripting languages can only use that default interface, they don't have a mechanism to retrieve another interface. Or in other words, they can't call QueryInterface(). Mostly because they don't support the notion of interfaces or casting or multiple inheritance at all in their language design. Intentionally, scripting languages are supposed to be easy to use.
So if interface1 was originally the default interface then the scripting programmer can never use the added interface2 methods. You'll want to have a look at this SO post to see the consequences.
You can keep COM interfaces backwards compatible with old client programs by only ever appending new methods and never change the order or arguments of the old ones. It is risky, an updated client program that accidentally meets an old version of your component will go up in flames in a very bad way. Usually very hard to diagnose, pure DLL Hell. Only truly safe way is to assign new [uuid]s, forcing the client program to be recompiled. If you also change the name or install location of the DLL then they can live side-by-side.