Immutable interfaces and adding methods

[DevonTaig]

I have a published interface and need to add a method to it. The litterature seems to indicate that the rules of COM dictate that I must create a new interface with a different name rather than simply add a new method. I am wondering why? Visual Basic allows me to maintain Binary Compatability when adding a new method, and I can't imagine why any existing clients would break. Why is the COM concept of "Immutable" so...well...immutable?

 

[JOLESEN]

I am no expert on DCOM, but if you just add an extra method to an existing interface, obviously you will end with 2 versions of the same interface - and you cannot tell which contains the extra method.
Any client using this new method will be in trouble if being used in an environment with the old version ....

Isn't that a very good reason to create a new interface ?

/JOlesen

 

[SemperFiDownUnda]

Yes VB does let you add in methods to a object without breaking compatibility BUT this is what I concider a bug more than anything. The Method MUST be at the end. The IDL then up to that point looks the same.

JOLESEN has a good point too. But as a purist no you shouldn't add a method to a interface after a program has been distributed that uses it.

 

[zalaki]

I think there is no problem in adding methods to an interface.Obviously it doesn't break the compatibility.(If the dll's are in binary compatible).But the old clients, which are already built using the old version of interface can't use these new methods.If at all they have to use them, we need to recompile our client exes which is not a good idea at all.We need to write new clients which use these newly added methods.