www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - OpEquals and Interfaces

reply Christoph Mueller <ruunhb googlemail.com> writes:
I'm currently writing a library in D2 which uses intensively interfaces 
and i meet a problem by overloading the opEquals Operator.

In some of my implementations i want to compare an object through an 
interface of another instance

Unfortanetly, the opEquals Operator uses only Object parameters and 
according to the current DMD-Compiler it's not possible to cast implicit 
an Interface to an Object. (Got a nice compiler error)

Is there any reason to forbid implicit downcasting from any interface to 
Object?

Of course, explicit downcasting cast(Object) is also possible, but 
casting everytime for == operator is not really nice.

Chris


-- 
ruunhb [AT] googlemail.com
http://www.ruuns.de/blog
Apr 13 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 13 Apr 2010 15:50:36 -0400, Christoph Mueller  
<ruunhb googlemail.com> wrote:


 I'm currently writing a library in D2 which uses intensively interfaces  
 and i meet a problem by overloading the opEquals Operator.

 In some of my implementations i want to compare an object through an  
 interface of another instance

 Unfortanetly, the opEquals Operator uses only Object parameters and  
 according to the current DMD-Compiler it's not possible to cast implicit  
 an Interface to an Object. (Got a nice compiler error)

 Is there any reason to forbid implicit downcasting from any interface to  
 Object?


Any good reason? No.

But the stated reason is usually that interfaces don't necessarily have to  
be Objects, they can be COM objects, which 1) has no bearing in some OSes,  
and 2) does anyone use this feature?


 Of course, explicit downcasting cast(Object) is also possible, but  
 casting everytime for == operator is not really nice.


If you are using D2, there is a workaround:

interface I
{
    final bool opEquals(I other)
    {
       Object me = cast(Object)this;
       Object they = cast(Object)other;
       return equals(me, they);
    }
}

But it would be nice if the compiler did this automatically.  There are  
other things that suck because interfaces are not assumed to be derived  
 from Object.

I think the whole COM interface hack needs to be revisited.

-Steve
Apr 13 2010
next sibling parent reply Christoph Mueller <ruunhb googlemail.com> writes:
 If you are using D2, there is a workaround:

 interface I
 {
 final bool opEquals(I other)
 {
 Object me = cast(Object)this;
 Object they = cast(Object)other;
 return equals(me, they);
 }
 }

 But it would be nice if the compiler did this automatically. There are
 other things that suck because interfaces are not assumed to be derived
 from Object.


What kind of things also doesn't work relating to interfaces and Object ?

-- 
ruunhb [AT] googlemail.com
http://www.ruuns.de/blog
Apr 13 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 13 Apr 2010 17:27:20 -0400, Christoph Mueller  
<ruunhb googlemail.com> wrote:


 If you are using D2, there is a workaround:

 interface I
 {
 final bool opEquals(I other)
 {
 Object me = cast(Object)this;
 Object they = cast(Object)other;
 return equals(me, they);
 }
 }

 But it would be nice if the compiler did this automatically. There are
 other things that suck because interfaces are not assumed to be derived
 from Object.


 What kind of things also doesn't work relating to interfaces and Object ?


Any base method of Object -- opCmp, toHash, or simply passing an interface  
to a function that accepts an Object.

There are others, but I can't think of them right now.

-Steve
Apr 13 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 13 Apr 2010 19:16:21 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 On Tue, 13 Apr 2010 17:27:20 -0400, Christoph Mueller  
 <ruunhb googlemail.com> wrote:


 If you are using D2, there is a workaround:

 interface I
 {
 final bool opEquals(I other)
 {
 Object me = cast(Object)this;
 Object they = cast(Object)other;
 return equals(me, they);
 }
 }

 But it would be nice if the compiler did this automatically. There are
 other things that suck because interfaces are not assumed to be derived
 from Object.


 What kind of things also doesn't work relating to interfaces and Object  
 ?


 Any base method of Object -- opCmp, toHash, or simply passing an  
 interface to a function that accepts an Object.


Add toString to that, that's a biggie...

-Steve
Apr 13 2010
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Christoph Mueller is asking the exact problem that I've been having. :)

Steven Schveighoffer wrote:


 If you are using D2, there is a workaround:

 interface I
 {
    final bool opEquals(I other)
    {
       Object me = cast(Object)this;
       Object they = cast(Object)other;
       return equals(me, they);


Is 'equals' a function on this interface?


    }
 }


I could not make that work. The compiler is still trying to call 
Object.opEquals.

At the risk of turning this forum to D.learn, I tried to have an 
explicit 'equals' member function on the interface and use that.

This is what I have:

import object;

interface I
{
     final bool opEquals(I other)
     {
         return equals(cast(Object)other);
     }

     bool equals(Object o);
}

class C : I
{
     override bool opEquals(Object o) const
     {
         return true;
     }

     bool equals(Object o)
     {
         return this == o;
     }
}

void main()
{
     I i = new C;
     i == i;         // <-- Error line
}

But it still calls Object.opEquals:

Error: function object.opEquals (Object lhs, Object rhs) is not callable 
using argument types (I,I)
Error: cannot implicitly convert expression (i) of type deneme.I to 
object.Object
Error: cannot implicitly convert expression (i) of type deneme.I to 
object.Object

Ali
Apr 13 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 13 Apr 2010 18:04:04 -0400, Ali Çehreli <acehreli yahoo.com> wrote:


 Christoph Mueller is asking the exact problem that I've been having. :)

 Steven Schveighoffer wrote:

  > If you are using D2, there is a workaround:
  >
  > interface I
  > {
  >    final bool opEquals(I other)
  >    {
  >       Object me = cast(Object)this;
  >       Object they = cast(Object)other;
  >       return equals(me, they);

 Is 'equals' a function on this interface?


No, it's a new global function in object.di, and it's called opEquals, not  
equals.  I guess I messed that up royally :)

Just do me == they;

That will call the function.


 But it still calls Object.opEquals:

 Error: function object.opEquals (Object lhs, Object rhs) is not callable  
 using argument types (I,I)


This is not Object.opEquals, it's object.opEquals -- note the  
capitalization.  The latter is a standalone function in module object.



 Error: cannot implicitly convert expression (i) of type deneme.I to  
 object.Object
 Error: cannot implicitly convert expression (i) of type deneme.I to  
 object.Object


This is a bug.  i == i should call the opEquals method on i.  Instead, the  
compiler is trying to call the standalone opEquals(Object, Object)  
function.

I confirmed with 2.043 that this is a bug.  I'll file with a test case.

-Steve
Apr 13 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 13 Apr 2010 19:13:31 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:



 I confirmed with 2.043 that this is a bug.  I'll file with a test case.


http://d.puremagic.com/issues/show_bug.cgi?id=4088
Apr 13 2010
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Steven Schveighoffer Wrote:


 Any good reason? No.
 
 But the stated reason is usually that interfaces don't necessarily have to  
 be Objects, they can be COM objects, which 1) has no bearing in some OSes,  
 and 2) does anyone use this feature?


Which feature? Interfaces? COM? upcasting? or opEquals?
I don't use opEquals. :3
Apr 13 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 13 Apr 2010 18:14:55 -0400, Kagamin <spam here.lot> wrote:


 Steven Schveighoffer Wrote:


 Any good reason? No.

 But the stated reason is usually that interfaces don't necessarily have  
 to
 be Objects, they can be COM objects, which 1) has no bearing in some  
 OSes,
 and 2) does anyone use this feature?


 Which feature? Interfaces? COM? upcasting? or opEquals?
 I don't use opEquals. :3


COM via D interfaces.

-Steve
Apr 13 2010
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Steven Schveighoffer Wrote:


 On Tue, 13 Apr 2010 15:50:36 -0400, Christoph Mueller  
 <ruunhb googlemail.com> wrote:
 

 I'm currently writing a library in D2 which uses intensively interfaces  
 and i meet a problem by overloading the opEquals Operator.

 In some of my implementations i want to compare an object through an  
 interface of another instance

 Unfortanetly, the opEquals Operator uses only Object parameters and  
 according to the current DMD-Compiler it's not possible to cast implicit  
 an Interface to an Object. (Got a nice compiler error)

 Is there any reason to forbid implicit downcasting from any interface to  
 Object?


 
 Any good reason? No.
 
 But the stated reason is usually that interfaces don't necessarily have to  
 be Objects, they can be COM objects, which 1) has no bearing in some OSes,  
 and 2) does anyone use this feature?


It could also be a C++ class
Apr 13 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 13 Apr 2010 19:47:13 -0400, Jason House  
<jason.james.house gmail.com> wrote:


 Steven Schveighoffer Wrote:


 On Tue, 13 Apr 2010 15:50:36 -0400, Christoph Mueller
 <ruunhb googlemail.com> wrote:


 I'm currently writing a library in D2 which uses intensively  


 interfaces

 and i meet a problem by overloading the opEquals Operator.

 In some of my implementations i want to compare an object through an
 interface of another instance

 Unfortanetly, the opEquals Operator uses only Object parameters and
 according to the current DMD-Compiler it's not possible to cast  


 implicit

 an Interface to an Object. (Got a nice compiler error)

 Is there any reason to forbid implicit downcasting from any interface  


 to

 Object?


 Any good reason? No.

 But the stated reason is usually that interfaces don't necessarily have  
 to
 be Objects, they can be COM objects, which 1) has no bearing in some  
 OSes,
 and 2) does anyone use this feature?


 It could also be a C++ class


C++ classes are already tagged with extern(C++) (i.e. there's a difference  
the compiler can grip to make it behave differently)

Maybe that's the solution, make COM solutions extern(COM), or  COM or  
something.  That's fine also.  Anything to then allow the compiler to  
assume unadorned interfaces are D objects.

-Steve
Apr 13 2010
next sibling parent reply Don <nospam nospam.com> writes:
Steven Schveighoffer wrote:

 On Tue, 13 Apr 2010 19:47:13 -0400, Jason House 
 <jason.james.house gmail.com> wrote:
 

 Steven Schveighoffer Wrote:


 On Tue, 13 Apr 2010 15:50:36 -0400, Christoph Mueller
 <ruunhb googlemail.com> wrote:


 I'm currently writing a library in D2 which uses intensively 


 interfaces

 and i meet a problem by overloading the opEquals Operator.

 In some of my implementations i want to compare an object through an
 interface of another instance

 Unfortanetly, the opEquals Operator uses only Object parameters and
 according to the current DMD-Compiler it's not possible to cast 


 implicit

 an Interface to an Object. (Got a nice compiler error)

 Is there any reason to forbid implicit downcasting from any 


 interface to

 Object?


 Any good reason? No.

 But the stated reason is usually that interfaces don't necessarily 
 have to
 be Objects, they can be COM objects, which 1) has no bearing in some 
 OSes,
 and 2) does anyone use this feature?


 It could also be a C++ class


 
 C++ classes are already tagged with extern(C++) (i.e. there's a 
 difference the compiler can grip to make it behave differently)
 
 Maybe that's the solution, make COM solutions extern(COM), or  COM or 
 something.  That's fine also.  Anything to then allow the compiler to 
 assume unadorned interfaces are D objects.
 
 -Steve


I think we can just use extern(C++).
Apr 14 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 14 Apr 2010 07:29:28 -0400, Don <nospam nospam.com> wrote:


 Steven Schveighoffer wrote:

 On Tue, 13 Apr 2010 19:47:13 -0400, Jason House  
 <jason.james.house gmail.com> wrote:


 Steven Schveighoffer Wrote:


 On Tue, 13 Apr 2010 15:50:36 -0400, Christoph Mueller
 <ruunhb googlemail.com> wrote:


 I'm currently writing a library in D2 which uses intensively  


 interfaces

 and i meet a problem by overloading the opEquals Operator.

 In some of my implementations i want to compare an object through an
 interface of another instance

 Unfortanetly, the opEquals Operator uses only Object parameters and
 according to the current DMD-Compiler it's not possible to cast  


 implicit

 an Interface to an Object. (Got a nice compiler error)

 Is there any reason to forbid implicit downcasting from any  


 interface to

 Object?


 Any good reason? No.

 But the stated reason is usually that interfaces don't necessarily  
 have to
 be Objects, they can be COM objects, which 1) has no bearing in some  
 OSes,
 and 2) does anyone use this feature?


 It could also be a C++ class


  C++ classes are already tagged with extern(C++) (i.e. there's a  
 difference the compiler can grip to make it behave differently)
  Maybe that's the solution, make COM solutions extern(COM), or  COM or  
 something.  That's fine also.  Anything to then allow the compiler to  
 assume unadorned interfaces are D objects.
  -Steve


 I think we can just use extern(C++).


If this is true, this is a no brainer!

This shows my ignorance of COM or why IUnknown is a special interface :)   
If it's just because it's a C++ interface, then yeah, let's set that up.

searching for D's explanation of how COM interfaces work I found this  
really helpful page :P

http://www.digitalmars.com/d/2.0/COM.html

Walter, can you confirm that extern(C++) interfaces are equivalent to  
inheriting IUnknown?  If not, what are the differences?

-Steve
Apr 14 2010
parent reply Kagamin <spam here.lot> writes:
Steven Schveighoffer Wrote:


 Walter, can you confirm that extern(C++) interfaces are equivalent to  
 inheriting IUnknown?  If not, what are the differences?


The difference is COM ABI is standardized, C++ ABI is implementation-defined.
If you are lucky, you can guess, which ABI is meant by extern(C++).
Apr 14 2010
parent reply Don <nospam nospam.com> writes:
Kagamin wrote:

 Steven Schveighoffer Wrote:
 

 Walter, can you confirm that extern(C++) interfaces are equivalent to  
 inheriting IUnknown?  If not, what are the differences?


 
 The difference is COM ABI is standardized, C++ ABI is implementation-defined.
If you are lucky, you can guess, which ABI is meant by extern(C++).


Well, yes, but C++ itself doesn't have interfaces. A COM interface is 
basically a MSVC virtual function table. Windows C++ compilers which 
support it, follow the Microsoft calling conventions, even if they use a 
different ABI for other classes.

The only problem would be if C++ subsequently defined interfaces (in 
C++1x) and they were different. I think that's extremely unlikely, since 
MSVC defines __interface to be a COM interface.

Note that extern(C++) is much more recent than the COM interface hack.
Apr 14 2010
parent reply Kagamin <spam here.lot> writes:
Don Wrote:


 I think that's extremely unlikely, since 
 MSVC defines __interface to be a COM interface.


It defines interface to be a C++ abstract class.
Apr 14 2010
parent reply Don <nospam nospam.com> writes:
Kagamin wrote:

 Don Wrote:
 

 I think that's extremely unlikely, since 
 MSVC defines __interface to be a COM interface.


 
 It defines interface to be a C++ abstract class.


Yeah, OK, __interface is slightly broader, it's a superset of COM 
interfaces.
But, all COM interfaces are C++ abstract classes. So, if we required 
extern(C++) in order to make it a COM interface, we'd be fine.
Then we'd have the rule: all interfaces are derived from Object, unless 
they are extern(C++).
Apr 15 2010
next sibling parent reply Kagamin <spam here.lot> writes:
Don Wrote:


 Then we'd have the rule: all interfaces are derived from Object, unless 
 they are extern(C++).


So all COM methods will be required to be declared extern(System)? Won't this
clash with extern function declaration?
Apr 15 2010
parent reply Don <nospam nospam.com> writes:
Kagamin wrote:

 Don Wrote:
 

 Then we'd have the rule: all interfaces are derived from Object, unless 
 they are extern(C++).


 
 So all COM methods will be required to be declared extern(System)? Won't this
clash with extern function declaration?


They have to use Windows calling conventions anyway.
Apr 15 2010
parent Kagamin <spam here.lot> writes:
Don Wrote:


 So all COM methods will be required to be declared extern(System)? Won't this
clash with extern function declaration?


 
 They have to use Windows calling conventions anyway.


Yes, but we already have C++ in-place constructor clash with function
declarations. Like
MyClass inst(1,2);
Apr 15 2010
prev sibling parent Kagamin <spam here.lot> writes:
Don Wrote:


 Then we'd have the rule: all interfaces are derived from Object, unless 
 they are extern(C++).


I'd propose rule "all extern(D) interfaces are implemented by objects derived
from Object", which is everything pure D type system needs, while allowing
extensions.
Apr 15 2010
prev sibling parent Kagamin <spam here.lot> writes:
Steven Schveighoffer Wrote:


 Maybe that's the solution, make COM solutions extern(COM), or  COM or  
 something.  That's fine also.


yes, extern(COM) must be from the start.
Apr 14 2010