On Tue, 13 Apr 2010 19:29:24 -0400, Steven Schveighoffer
<schvei...@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.