www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is it time to deprecate COM compatibility through D interfaces?

reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Apr 13 2010
next sibling parent "Yao G." <nospamyaoltzin gmail.com> writes:
On Tue, 13 Apr 2010 19:29:24 -0400, Steven Schveighoffer  
<schveiguy 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.
Apr 13 2010
prev sibling next sibling parent "Yao G." <nospamyaoltzin gmail.com> writes:
On Tue, 13 Apr 2010 19:29:24 -0400, Steven Schveighoffer  
<schveiguy 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 :)
Apr 13 2010
prev sibling next sibling parent Richard Webb <webby beardmouse.org.uk> writes:
I've done a bit of tinkering with the Juno library
(http://www.dsource.org/projects/juno) to both automate Office applications,
and to write a simple COM addin for Outlook. In both cases, that was using a
tool that creates D interface definitions from a COM type library.

My knowledge of D is still pretty slim though, and i haven't thought much about
alternate approaches to this.
Apr 14 2010
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
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.
 
 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.
Apr 14 2010
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Fawzi Mohamed wrote:
 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.

Are these in bugzilla?
Apr 14 2010
prev sibling parent Fawzi Mohamed <fawzi gmx.ch> writes:
On 14-apr-10, at 15:55, Walter Bright wrote:

 Fawzi Mohamed wrote:
 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.

Are these in bugzilla?

the delegate one: http://d.puremagic.com/issues/show_bug.cgi?id=3706 delegates of interfaces with multiple inheritance fail about multiple inheritance, I might misremember, I know that I had to cast through Object in my Serialization function, but I don't know anymore exactly why, I haven't found a relevant bug, and my simple experiments with casting seem to work... by the way also http://d.puremagic.com/issues/show_bug.cgi?id=2683 Cannot implement interface methods by alias is annoying, makes the use of templates to implement interfaces cumbersome.
Apr 14 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 14 Apr 2010 08:22:59 -0400, Jason House  
<jason.james.house 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.
 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. -Steve
Apr 14 2010
prev sibling next sibling parent Fawzi Mohamed <fawzi gmx.ch> writes:
On 14-apr-10, at 15:10, Steven Schveighoffer wrote:

 On Wed, 14 Apr 2010 08:22:59 -0400, Jason House <jason.james.house 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.
Apr 14 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 14 Apr 2010 09:34:38 -0400, Fawzi Mohamed <fawzi gmx.ch> wrote:

 On Wed, 14 Apr 2010 08:22:59 -0400, Jason House  
 <jason.james.house gmail.com> wrote:

 Don suggested defining them the same way as C++ classes.


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).

I don't think this will ever happen. Since D is moving towards outlawing referencing stack data in safeD, this would mean struct interfaces are most likely illegal in safeD. Add to this the fact that then structs need a vtable, and you have started to stray from some of the benefits of structs. I just don't see it being worth it. And I did want struct interfaces too. We always have compile-time interfaces for structs (i.e. template constraints) that also work on classes. -Steve
Apr 14 2010
prev sibling next sibling parent Fawzi Mohamed <fawzi gmx.ch> writes:
On 14-apr-10, at 16:08, Steven Schveighoffer wrote:

 On Wed, 14 Apr 2010 09:34:38 -0400, Fawzi Mohamed <fawzi gmx.ch>  
 wrote:

 On Wed, 14 Apr 2010 08:22:59 -0400, Jason House <jason.james.house gmail.com 
 wrote:

 Don suggested defining them the same way as C++ classes.


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).

I don't think this will ever happen. Since D is moving towards outlawing referencing stack data in safeD, this would mean struct interfaces are most likely illegal in safeD. Add to this the fact that then structs need a vtable, and you have started to stray from some of the benefits of structs. I just don't see it being worth it. And I did want struct interfaces too. We always have compile-time interfaces for structs (i.e. template constraints) that also work on classes.

it makes sense, I wanted just to point out the consequence, so that this a design decision is done being aware of that.
Apr 14 2010
prev sibling parent Kagamin <spam here.lot> writes:
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?
 

 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.

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.

 - 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.
 

 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?
 

Apr 14 2010