On 14-apr-10, at 15:10, Steven Schveighoffer wrote:
On Wed, 14 Apr 2010 08:22:59 -0400, Jason House <jason.james.ho...@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.
