digitalmars.D - Is it time to deprecate COM compatibility through D interfaces?
- Steven Schveighoffer (21/21) Apr 13 2010 Given that structs have become extremely powerful, and with the advent o...
- Yao G. (9/31) Apr 13 2010 I use them to create and manipulate Word and Excel documents thru
- Yao G. (6/28) Apr 13 2010 Sorry Steve. I just read the messages about opCmp and interfaces, and yo...
- Richard Webb (2/2) Apr 14 2010 I've done a bit of tinkering with the Juno library (http://www.dsource.o...
- Jason House (3/17) Apr 14 2010 Casting interfaces is frequently an expensive runtime operation. It's th...
- Steven Schveighoffer (10/34) Apr 14 2010 Yes, if that is possible, I agree with that solution. Essentially, COM ...
- Fawzi Mohamed (12/53) Apr 14 2010 I like this, implicit casting to object would be very convenient, but
- Walter Bright (2/9) Apr 14 2010 Are these in bugzilla?
- Fawzi Mohamed (13/22) Apr 14 2010 the delegate one:
- Steven Schveighoffer (10/19) Apr 14 2010 I don't think this will ever happen. Since D is moving towards outlawin...
- Fawzi Mohamed (3/22) Apr 14 2010 it makes sense, I wanted just to point out the consequence, so that
- Kagamin (9/32) Apr 14 2010 1. Interfaces don't derive from object.
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
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. -SteveI 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
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. -SteveSorry 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
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
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
On Wed, 14 Apr 2010 08:22:59 -0400, Jason House <jason.james.house gmail.com> wrote:Steven Schveighoffer Wrote: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.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.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. -SteveThere 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
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.comI 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).wrote:Steven Schveighoffer Wrote: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.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.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.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.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
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
On 14-apr-10, at 15:55, Walter Bright wrote:Fawzi Mohamed wrote: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.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
On Wed, 14 Apr 2010 09:34:38 -0400, Fawzi Mohamed <fawzi gmx.ch> wrote: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. -SteveOn Wed, 14 Apr 2010 08:22:59 -0400, Jason House <jason.james.house gmail.com> wrote: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).Don suggested defining them the same way as C++ classes.
Apr 14 2010
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:it makes sense, I wanted just to point out the consequence, so that this a design decision is done being aware of that.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.On Wed, 14 Apr 2010 08:22:59 -0400, Jason House <jason.james.house gmail.comI 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).wrote:Don suggested defining them the same way as C++ classes.
Apr 14 2010
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.
Apr 14 2010