Comparing interfaces does not call opEquals

[Bill Baxter]

On Wed, Jul 30, 2008 at 5:03 AM, Jarrett Billingsley <kb3ctd2 at yahoo.com> wrote:
>
> --------------------------------------
> "Bill Baxter" <wbaxter at gmail.com> wrote in message
> news:mailman.2.1217360707.1156.digitalmars-d at puremagic.com...
>
> What is the reason that COM interfaces need to pretend to be D interfaces in
> the first place?  As opposed to some special COMInterface type.  I can't
> really think of any situation where you would need to treat a COM interface
> and a regular interface the same way without knowing that one was a COM
> interface.  Or at least in a way that it would matter.  For instance you
> could write a template that takes either a COM interface or a D interface,
> but in that case you generally won't care what the thing is underneath.
>
> Can someone enlighten me?  I've never really been able to understand what
> problem is supposed to be solved by conflating D Interfaces and COM
> interfaces.
>
> --bb
>
> Bill, could you post in plaintext please?

Sorry 'bout that.  Gmail makes it too easy not to notice what mode
you're in.  Wish it had a way to set the rich/plaintext mode
automatically based on To address...

> I've never been able to figure it out either.  COM is a dying technology on
> a closed platform.  It seems arbitrary to deem it for inclusion as a core
> language feature in a cross-platform language, and when it starts making
> other things impossible, like casting interfaces to objects, it seems more
> like a ball-and-chain.  In ten years, will the inclusion of COM interfaces
> really seem like such a good idea?
>
> Smells of "all the world's a Windows machine" to me.

I think some people in this thread hinted that a similar tactic could
be used to support other external object systems.  So, yeh, if it's
just COM, it seems rather odd.  But I think you could probably
incorporate CORBA objects or whatever into D in a similar way.  Having
such a mechanism seems useful, I suppose.  These days, though, trying
to use metaprogramming and compile time-reflection to automate
interfacing with foreign object systems makes more sense, I think.

It seems like not even C# has such a huge special case for COM.  I
found this description on the web about how to access a COM object
from .NET:  "You set up the reference in the project and VS.NET
creates an interop object for you to use to call the COM object."   So
it sounds like the tool creates the boilerplate for you, wrapping up
the COM object inside an ordinary object.  So not even MS thought it
was a good idea to build COM into the language spec.

--bb