View mode: basic / threaded / horizontal-split · Log in · Help
February 10, 2007
Object and interface compatibility
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?
February 10, 2007
Re: Object and interface compatibility
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
February 10, 2007
Re: Object and interface compatibility
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.
February 10, 2007
Re: Object and interface compatibility
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)
February 10, 2007
Re: Object and interface compatibility
> 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++
February 11, 2007
Re: Object and interface compatibility
"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.
February 11, 2007
Re: Object and interface compatibility
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.
February 11, 2007
Re: Object and interface compatibility
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.
February 11, 2007
Re: Object and interface compatibility
"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..
February 11, 2007
Re: Object and interface compatibility
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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home