www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Comparing interfaces does not call opEquals

reply Frank Benoit <keinfarbton googlemail.com> writes:
interface I {
}
class C : I {
   override int opEquals(Object o){
     writefln("opEquals");
     return true;
   }
}

void main(){
   I i1 = new C;
   I i2 = new C;
   bool a = ( i1 == i2 );
   writefln( "result %s", a );
}

prints
result false

This is highly unexpected.
Sure one might understand that with the knowledge of interface/class 
incompatibility in D. But this shows once more, that D has a Bug here.
Jul 29 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
Content-Disposition: inline

On Wed, Jul 30, 2008 at 3:06 AM, Frank Benoit <keinfarbton googlemail.com>wrote:


 interface I {
 }
 class C : I {
  override int opEquals(Object o){
    writefln("opEquals");
    return true;
  }
 }

 void main(){
  I i1 = new C;
  I i2 = new C;
  bool a = ( i1 == i2 );
  writefln( "result %s", a );
 }

 prints
 result false

 This is highly unexpected.
 Sure one might understand that with the knowledge of interface/class
 incompatibility in D. But this shows once more, that D has a Bug here.


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
Jul 29 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
--------------------------------------
"Bill Baxter" <wbaxter gmail.com> wrote in message 
news:mailman.2.1217360707.1156.digitalmars-d 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?

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.
Jul 29 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Wed, Jul 30, 2008 at 5:03 AM, Jarrett Billingsley <kb3ctd2 yahoo.com> wrote:

 --------------------------------------
 "Bill Baxter" <wbaxter gmail.com> wrote in message
 news:mailman.2.1217360707.1156.digitalmars-d 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.


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
Jul 29 2008