Is it time to deprecate COM compatibility through D interfaces?

[Yao G.]

On Tue, 13 Apr 2010 19:29:24 -0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> Given that structs have become extremely powerful, and with the advent  
> of opDispatch, would it be possible to deprecate supporting COM via D  
> interfaces in favor of a library solution?
>
> There are some crappy drawbacks for having interface be dual-purposed:
>
> - Although 99.9% of interfaces are actually instances of Object, you  
> can't call Object functions directly on an interface.  This includes  
> opEquals, opCmp, toString and friends.
> - They are not implicitly castable to Object.
> - There is no centralized base interface, so there is no argument type  
> you can use that can accept any interface.  For instance, if you wanted  
> to do some runtime reflection to determine an interface's methods or  
> something.
> - All these drawbacks are absolutely pointless on non-Microsoft OSes.
>
> We are in the process of getting rid of builtin complex types in favor  
> of library types -- can we do something similar?
>
> I admit I am not familiar with COM, except my few experiences with it I  
> hated :)  Does anyone actually use D interfaces to represent COM  
> objects?  What would the drawbacks be of interfacing COM objects via  
> compile-time generated structs that do the busy work?
>
> Another possibility is simply making normal interfaces derive from  
> Object, and COM interfaces not.  I think this has been discussed before.
>
> -Steve

I use them to create and manipulate Word and Excel documents thru  
Automation. But yes, I think that it overcomplicates the implementation of  
interfaces for something that is not that common. Another possibility is  
to create a property, maybe @cominterface or something, and only those  
interfaces marked with that property would work with COM.

Although I don't know the feasibility of this, or if it complicates the  
language.