Is it time to deprecate COM compatibility through D interfaces?

[Fawzi Mohamed]

On 14-apr-10, at 15:10, Steven Schveighoffer wrote:

> On Wed, 14 Apr 2010 08:22:59 -0400, Jason House <jason.james.house at gmail.com 
> > wrote:
>
>> 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?
>>
>> Don suggested defining them the same way as C++ classes.
>
> Yes, if that is possible, I agree with that solution.  Essentially,  
> COM interfaces simply become C++ interfaces, there is no special  
> treatment for them, and non-C++ interfaces can be assumed to derive  
> from Object.

I like this, implicit casting to object would be very convenient, but  
note that that precludes the possibility of ever having structs  
implement interfaces (not that they should, but as of now it is kind  
of possible to imagine).


>>> 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.
>>
>> Casting interfaces is frequently an expensive runtime operation.  
>> It's the price that we pay for allowing more than single  
>> inheritance with interfaces. I don't like the idea of implicitly  
>> doing expensive operations.
>
> Casting interfaces to Object would not be expensive if the compiler  
> knows every interface is an Object.  All that is required is to  
> subtract the offset, found in the TypeInfo of the interface.  The  
> expensive part of casting is searching for the typeinfo to ensure  
> the cast is legal.

please note that multiple inheritance in interfaces is still buggy,  
things like casting directly an interface to another (without casting  
to object first) or taking a delegate to a method of a super interface  
that is not the first one fail in ugly ways.
I have become very wary of interfaces because of this, and try to  
avoid multiple inheritance in them as much as possible...
I hope it will be fixed.