www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Object and interface compatibility

reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Interfaces are NOT compatible to Object.

interface I{
 void func();
}
class C : I {
 void func(){}
}

void main(){
 I i = new C;
 i.func();                 // OK
 i.toHash();               // error !!
 (cast(C)i).toHash();      // OK
 (cast(Object)i).toHash(); // OK
}

I think this is a failure in the language design. What do you think?
Feb 10 2007
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Frank Benoit (keinfarbton) wrote:

 Interfaces are NOT compatible to Object.
 
 interface I{
  void func();
 }
 class C : I {
  void func(){}
 }
 
 void main(){
  I i = new C;
  i.func();                 // OK
  i.toHash();               // error !!
  (cast(C)i).toHash();      // OK
  (cast(Object)i).toHash(); // OK
 }
 
 I think this is a failure in the language design. What do you think?


I think it isn't a failure unless it prevents some expected core functionality. 
Interfaces are a contract declaring specific small set of members that should
be 
available, and make zero guarantees about what else the Object may have going
on.

Unfortunately in the case of D, it does prevent something: the use of
Interfaces as AA 
keys.  Although, perhaps the thing to do is to have a "standard" IComparable
interface 
that declares opCmp, opEquals, and toHash.  Or, have a "root interface"
named... 
Interface, I suppose, which declares the same.  (We could even then redeclare
Object as 
Object:Interface.)  Then have all user-defined interfaces without explicit
inheritance 
derive from Interface the same way classes do from Object.

-- Chris Nicholson-Sauls
Feb 10 2007
parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
a root interface 'Interface' does not solve the problem because of D
strange reimplementation rule. Every time you implement an interface,
you would need to reimplement or alias all methods from Object.
Feb 10 2007
parent reply Johan Granberg <lijat.meREM OVE.gmail.com> writes:
Frank Benoit (keinfarbton) wrote:


 a root interface 'Interface' does not solve the problem because of D
 strange reimplementation rule. Every time you implement an interface,
 you would need to reimplement or alias all methods from Object.


But maybe it is the reimplementation rules that should be changed.

I like the idea of a root interface (in languages with a root object)
Feb 10 2007
next sibling parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
 But maybe it is the reimplementation rules that should be changed.
 
 I like the idea of a root interface (in languages with a root object)


vote++
Feb 10 2007
prev sibling parent BCS <ao pathlink.com> writes:
Reply to Johan,


 But maybe it is the reimplementation rules that should be changed.
 


vote += .5

I like the idea, but I'm thinking it might have some issues. I can't see 
any now but I've just got a feeling.


 I like the idea of a root interface (in languages with a root object)
 


vote--

I wouldn't mind /to/ much having Object using an interface (I'd rather not) 
but don't make an implicit root interface. It would disallow compile time 
banning of an operation.
Feb 11 2007
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> wrote in 
message news:eqkuqa$3v1$1 digitaldaemon.com...

 Interfaces are NOT compatible to Object.

 interface I{
 void func();
 }
 class C : I {
 void func(){}
 }

 void main(){
 I i = new C;
 i.func();                 // OK
 i.toHash();               // error !!
 (cast(C)i).toHash();      // OK
 (cast(Object)i).toHash(); // OK
 }

 I think this is a failure in the language design. What do you think?


I think it's because an interface may or may not be pointing to a D object. 
If you create a COM interface, for example, there's no associated D object, 
so there's no way for D to create a hash for it.  It's basically just a 
pointer.

This could be solved by having a "cominterface" type which behaves like 
interfaces currently do, and change interfaces to be more integrated into D. 
Probably never going to happen.
Feb 10 2007
next sibling parent "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
I really don't like the idea, that D has an inconsistent design, only to
have the COM feature.
Doing the special solution for this special case, would be much better.
Feb 10 2007
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jarrett Billingsley wrote:

 "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> wrote in 
 message news:eqkuqa$3v1$1 digitaldaemon.com...

 Interfaces are NOT compatible to Object.

 interface I{
 void func();
 }
 class C : I {
 void func(){}
 }

 void main(){
 I i = new C;
 i.func();                 // OK
 i.toHash();               // error !!
 (cast(C)i).toHash();      // OK
 (cast(Object)i).toHash(); // OK
 }

 I think this is a failure in the language design. What do you think?


 
 I think it's because an interface may or may not be pointing to a D object. 
 If you create a COM interface, for example, there's no associated D object, 
 so there's no way for D to create a hash for it.  It's basically just a 
 pointer.


But isn't this only true for COM interfaces? The compiler knows when 
compiling "i.toHash();" whether or not typeof(i) is an interface 
inheriting from IUnknown, doesn't it? So it could make this work for all 
other interfaces...


 This could be solved by having a "cominterface" type which behaves like 
 interfaces currently do, and change interfaces to be more integrated into D. 
 Probably never going to happen. 


It's much easier solved by checking if "IUnknown" is a base of the 
interface in question.
Feb 11 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Frits van Bommel" <fvbommel REMwOVExCAPSs.nl> wrote in message 
news:eqmlfe$1e3v$1 digitalmars.com...


 But isn't this only true for COM interfaces? The compiler knows when 
 compiling "i.toHash();" whether or not typeof(i) is an interface 
 inheriting from IUnknown, doesn't it? So it could make this work for all 
 other interfaces...


You know, that's entirely right.  The compiler should be able to do this.


 It's much easier solved by checking if "IUnknown" is a base of the 
 interface in question.


In fact, the compiler already seems to do this..
Feb 11 2007
prev sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
Frank Benoit (keinfarbton) wrote:

 Interfaces are NOT compatible to Object.
 
 interface I{
  void func();
 }
 class C : I {
  void func(){}
 }
 
 void main(){
  I i = new C;
  i.func();                 // OK
  i.toHash();               // error !!
  (cast(C)i).toHash();      // OK
  (cast(Object)i).toHash(); // OK
 }
 
 I think this is a failure in the language design. What do you think?


I don't think it's a failure. Like others have said, the interface may 
or may not be part of a D Object. You can cast to make sure:

Object o = cast(Object)iface;
if (o) {
   // it's a D object; o.toHash is available
}
else {
   // not a D object; panic
}

L.
Feb 13 2007