Steven Schveighoffer 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? > COM interface is not a D interface.
> 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. 1. Interfaces don't derive from object. 2. You always know which interface is a D interface and which isn't, so you always know, whether you can cast it to object or not. > - They are not implicitly castable to Object. This has nothing to do with COM interfaces, I believe. > - 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. This is irrelevant to COM interfaces either. Can you use Variant for this purpose? > - All these drawbacks are absolutely pointless on non-Microsoft OSes. > They are pointless on ms oses too. And have nothing to do with COM. And dmd supports XPCOM. > We are in the process of getting rid of builtin complex types in favor of > library types -- can we do something similar? > If you have a solution, we can. > 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? > Syntax, I suppose.
