Confused about interfaces in D

[Bill Baxter]

On Fri, Oct 3, 2008 at 8:42 AM, Jarrett Billingsley
<jarrett.billingsley at gmail.com> wrote:
> On Thu, Oct 2, 2008 at 7:36 PM, Bryan Power <bp2626 at yahoo.com> wrote:
>> Bill Baxter wrote:
>>>
>>> When it's derived from IUnknown, a special case put in to support COM
>>> interfaces on Win32.
>>> I've not heard anyone voice support for this particular design decision.
>>> I suppose it's very convenient if you happen to be a COM programmer,
>>> but I'm not sure why a vendor-specific technology like COM should get
>>> such special treatment in a language spec.
>>>
>>> --bb
>>
>> Steven Schveighoffer wrote:
>>>
>>> The issue is totally with COM.
>>>
>>> Without the requirement for any interface to possibly be a COM interface,
>>> all interfaces would implicitly inherit from ObjectInterface or some
>>> interface that always has the functions required in Object defined (e.g.
>>> toString()).
>>>>
>>> But COM objects don't have the same base functions as Object does, so
>>> interfaces have no required base functions.  Making life difficult for those
>>> who never ever work with COM (and I can't say I blame them, COM sucks).
>>>
>>> -Steve
>>
>> A fair bit of extended API functionality on Windows is presented via COM.
>> This includes very important API sets like DirectX, which is implemented via
>> COM. A bonus of COM is that it allows use of the API in its OOP form in C++
>> while still allowing the API to be used in procedural languages like IA32, C
>> and Pascal without any hacks or tricks.
>>
>> Even Mozilla has their own COM implementation.
>>
>> While I admit COM can be messy at times, I use it almost daily for my work,
>> and since I am free to use the languages of my choosing I generally use D.
>> This interface feature allows me to port COM definitions from the C/C++
>> headers to D seamlessly
>> and quickly:
>>
>> interface IWbemObjectSink : IUnknown {}
>>
>> for example.
>>
>> I am all for the COM compatibility.
>>
>
> I am as well, but treating it as the general case makes no sense.
> IUnknown and anything derived from it should be treated as special
> cases; anything else should be implicitly castable to Object.

Same here.  I have nothing against support for COM, just support for
COM that complicates the common case for everyone just for the benefit
of being able to use COM.

I don't think such a compromise is required.  But I also don't have an
alternate design I can provide.  I suspect that along the lines of
what Ja-double-r-e-double-t says, there could be a foreign_interface
type in D that objects can derive from.  IUnknown could be one such
foreign_interface.

But that may just be making a bad situation worse.
I'm pretty sure from looking at the DirectX headers that you can do
COM in C++ without any fancy compiler support, so it seems likely that
there could be a completely different approach to supporting COM (and
other things) in a more general way via mixins and (someday) macros.
Or maybe some new compile-time decorator syntax.

--bb