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

Sorry Steve. I just read the messages about opCmp and interfaces, and you  
proposed something similar to what I wrote in my previous message. Well,  
at least it indicates that it's something that surfaces frequently and  
more than one have though about that :)