February 10, 2007
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
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
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
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
> 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
"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
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
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
"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
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