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

"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

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

"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 :)

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.

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.

"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

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.

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?

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.

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


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

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

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.


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

 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.

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?
 

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.